Summary

  • ALTO Cost Calendars give applications a sequence of network-cost values for future intervals, so a workload can choose when as well as where to send traffic.
  • The values are provider-published guidance, not forwarding commands or guaranteed measurements. They are meaningful only with the declared cost type, time scope and dependent map versions.
  • A safe deployment needs fresh updates, observation of the actual result and a fallback when an incident, a missed update or the clients' own response makes the forecast wrong.

The cheapest slot is an assertion

Imagine a scheduler with a large replication job and a six-hour deadline. Its ALTO response shows a lower cost between two network locations after 02:00. The scheduler waits. Nothing in that decision changes BGP, reserves a circuit or instructs a router. The application has accepted a statement published by an information service: for this source, this destination, this cost type and this interval, later is preferable to now.

That distinction is the centre of the design. RFC 7285 created the Application-Layer Traffic Optimization protocol for applications that have a choice of endpoints. A network map groups endpoints into provider-defined identifiers, or PIDs. A cost map then supplies directed costs between those groups. The publisher can express a numerical value or an ordinal ranking without exposing the topology, traffic-engineering rules or commercial facts from which it was derived.

ALTO calls the result the network region's own view of the Internet. It is deliberately an abstraction. A value of 20 need not mean 20 milliseconds, 20 dollars or 20 congested links. Unless the declared metric assigns a real unit, the useful fact is comparative: this path or interval ranks differently from another under the publisher's model.

A calendar adds time, not certainty

RFC 8896 extends that model with a Cost Calendar. Instead of returning one value for a source-destination pair, the server can return an array of values covering consecutive intervals. Metadata states when the calendar starts, how long each interval lasts and how many intervals it contains. The application can therefore decide not only where to connect but when to run work such as a bulk transfer.

The calendar may be built from a repeated pattern, a planned maintenance window or statistics from previous periods. That is useful operational knowledge, but it is still a forecast. A fibre cut, an unexpected crowd, a failed cache or a sudden routing change can make the published quiet hour busy. A repeated calendar can be internally valid and still describe a day that no longer exists.

This is why a timestamp is not decorative metadata. A client has to know the calendar's start time and interval boundaries, the cost type being described and the network-map version on which the source and destination groups depend. Applying tomorrow's array to today's map, or reading the third element in the wrong timezone, produces a decision that no ALTO server actually recommended.

Freshness has its own protocol

The base ALTO model lets a client fetch a resource again. That is inefficient when a large map changes only in a few places and too slow when the recommendation matters now. RFC 8895 adds an update stream using Server-Sent Events. A server can push a full replacement or an incremental change encoded as JSON Merge Patch or JSON Patch.

The update channel is a second control surface, not an automatic cure. The client must bind each event to the right resource and base version, keep messages in order, and handle a stream interruption without pretending its last copy is current. A tiny patch applied to the wrong calendar can be more dangerous than a clearly absent response because it leaves a plausible but invented schedule.

RFC 8896 therefore recommends that calendar deployments also support the incremental-update service. The practical test is not merely whether an SSE connection is open. It is whether a change at the publisher becomes the same change in the scheduler's active decision state, with a traceable version and a bounded delay.

Guidance changes the thing being forecast

A calendar does more than describe demand. It can move demand. If many clients receive the same low-cost interval, they may all defer work to it. The cheap window then fills because it was advertised as cheap. RFC 8896 explicitly asks operators to consider this feedback effect when publishing and consuming calendar values.

That creates a quiet coordination problem. A coarse calendar protects confidential network detail and reduces churn, but it can herd a large population into the same bucket. A fine calendar may spread choices more precisely, yet it reveals more about operating conditions and requires more updates. A publisher may prefer stability; a latency-sensitive application may value immediacy; a bulk scheduler may prefer predictability. The protocol carries the guidance, but it does not make those interests identical.

The information also has an adversarial use. A compromised client could use a calendar to choose a promising time for abusive traffic. Authentication can show who published the guidance. It cannot ensure that every consumer will use it for the publisher's intended purpose.

What the RFC record proves

The fixed record proves the data model: provider-defined network locations, directed costs, time intervals and a mechanism for pushing replacements or patches. It proves that the designers recognized stale forecasts, feedback effects, undesirable authenticated guidance, client instability and malicious use.

It does not prove that a named operator runs an ALTO service, that a calendar reflects real price or congestion, or that following one improves a particular transfer. Those are deployment claims requiring service-specific evidence. An RFC can define how a recommendation is expressed; only the operator and the observing client can show whether that recommendation was fresh, suitable and effective.

Sources