Zusammenfassung

  • Ein ALTO Cost Calendar liefert eine Folge von Netzkosten für künftige Intervalle, sodass eine Anwendung neben dem Ziel auch den Zeitpunkt einer Übertragung wählen kann.
  • Die Werte sind veröffentlichte Hinweise eines Anbieters, keine Weiterleitungsbefehle und keine Garantie für Preis, Latenz oder Kapazität.
  • Ein belastbarer Einsatz prüft Kostentyp, Zeitraum und abhängige Kartenversionen, empfängt Änderungen und behält einen Ersatzweg, wenn die Prognose nicht mehr zur Netzlage passt.

Das günstigste Zeitfenster ist eine Behauptung

Ein Scheduler soll vor Tagesanbruch eine große Replikation abschließen. Die ALTO-Antwort zeigt zwischen zwei Netzregionen nach 02:00 einen niedrigeren Wert. Der Scheduler wartet. Damit wird weder BGP verändert noch eine Leitung reserviert oder ein Router angewiesen. Die Anwendung akzeptiert eine Aussage des Informationsdienstes: Für diese Quelle, dieses Ziel, diesen Kostentyp und dieses Intervall scheint später besser zu sein als jetzt.

RFC 7285 definiert Application-Layer Traffic Optimization für Anwendungen, die zwischen Endpunkten wählen können. Eine Netzkarte fasst Adressen in anbieterdefinierte Kennungen, sogenannte PIDs, zusammen. Eine Kostenkarte veröffentlicht gerichtete Werte zwischen diesen Gruppen.

Diese Sicht ist bewusst abstrakt. Der Betreiber kann eine Rangfolge oder Zahlen ohne reale Maßeinheit offenlegen, ohne interne Topologie, Traffic-Engineering-Regeln oder Geschäftsbedingungen preiszugeben. Der Wert 20 bedeutet deshalb nicht automatisch zwanzig Millisekunden, zwanzig Geldeinheiten oder zwanzig überlastete Verbindungen. Solange die Metrik keine reale Einheit festlegt, zählt der Vergleich innerhalb derselben veröffentlichten Sicht.

Zeit schafft keine Gewissheit

RFC 8896 ergänzt das Modell um den Cost Calendar. Statt eines einzelnen Werts für ein Quell-Ziel-Paar liefert der Server ein Feld für aufeinanderfolgende Intervalle. Metadaten bestimmen Beginn, Dauer und Anzahl, damit eine Anwendung den Zeitpunkt einer aufschiebbaren Arbeit wählen kann.

Der Kalender kann aus historischen Mustern, geplanter Wartung oder einem erwarteten Zyklus abgeleitet sein. Das ist nützliches Betriebswissen, bleibt aber eine Zukunftsaussage. Ein Glasfaserbruch, eine unerwartete Menschenmenge, ein Cache-Ausfall oder eine Routing-Änderung kann die angekündigte Ruhephase in eine Spitze verwandeln. Ein wiederholter Kalender kann formal korrekt sein und dennoch einen Tag beschreiben, den es nicht mehr gibt.

Der zeitliche Kontext ist daher kein Schmuck. Der Client braucht Startzeit, Zeitzone, Intervallgrenzen, Kostentyp und Versionen der Karten, die den PIDs Bedeutung geben. Wer das Feld von morgen auf die Karte von heute anwendet oder wegen einer falschen Zeitzone den dritten Eintrag verwechselt, erzeugt eine Entscheidung, die der Server nie empfohlen hat.

Aktualität hat ein eigenes Protokoll

Im Basisverfahren kann der Client eine Ressource vollständig neu laden. Das ist verschwenderisch, wenn sich in einer großen Karte nur wenige Zellen ändern, und möglicherweise zu langsam für eine aktuelle Entscheidung. RFC 8895 definiert einen Aktualisierungsstrom mit Server-Sent Events. Der Server kann einen vollständigen Ersatz oder eine inkrementelle Änderung als JSON Merge Patch oder JSON Patch senden.

Der Strom ist eine zweite Steuerungsfläche, keine automatische Heilung. Der Client muss jedes Ereignis an die richtige Ressource und Ausgangsversion binden, die Reihenfolge wahren und nach einer Unterbrechung seine letzte Kopie nicht als aktuell ausgeben. Ein kleiner Patch auf dem falschen Kalender kann gefährlicher sein als eine fehlende Antwort: Er hinterlässt einen glaubwürdigen Zeitplan, den niemand veröffentlicht hat.

RFC 8896 empfiehlt deshalb, Kalender und inkrementelle Updates gemeinsam einzusetzen. Eine offene SSE-Verbindung beweist keine Aktualität. Entscheidend ist, dass eine Änderung beim Herausgeber als dieselbe Änderung in den aktiven Entscheidungszustand des Schedulers gelangt — mit nachvollziehbarer Version und begrenzter Verzögerung.

Die Empfehlung verändert ihre eigene Prognose

Ein Kalender beschreibt Nachfrage nicht nur, er verschiebt sie. Erhalten viele Clients dasselbe günstige Intervall, können alle ihre Arbeit dorthin verlegen. Das ruhige Fenster füllt sich, weil es als ruhig angekündigt wurde. RFC 8896 verlangt ausdrücklich, diesen Rückkopplungseffekt zu berücksichtigen.

Die Granularität wird damit zur Betriebsentscheidung. Ein grober Kalender schützt vertrauliche Informationen besser und ändert sich seltener, sammelt aber mehr Clients in demselben Block. Ein feiner Kalender verteilt Entscheidungen genauer, offenbart jedoch mehr Betriebszustand und verlangt häufigere Updates. Das Netz möchte vielleicht einen teuren Link entlasten, während die Anwendung eine Frist halten muss. Das Protokoll ermöglicht Abstimmung, macht die Interessen aber nicht gleich.

Auch ein Angreifer kann die Information nutzen. Ein kompromittierter Client könnte einen scheinbar günstigen Zeitpunkt für missbräuchlichen Verkehr auswählen. Authentisierung belegt den Herausgeber, nicht die Absicht jedes Lesers.

Was die RFCs belegen

Die Primärquellen belegen das Datenmodell: anbieterdefinierte Netzorte, gerichtete Kosten, Zeitintervalle und vollständige oder inkrementelle Änderungen. Sie zeigen auch, dass veraltete Prognosen, Rückkopplung, authentisierte, aber schädliche Hinweise, Client-Instabilität und Missbrauch berücksichtigt wurden.

Sie belegen nicht, dass ein bestimmter Betreiber ALTO einsetzt, dass ein Wert echten Preis oder echte Auslastung darstellt oder dass eine einzelne Übertragung besser wird. Eine RFC definiert die Darstellung einer Empfehlung. Nur Beobachtungen des konkreten Dienstes und Clients können zeigen, ob sie aktuell, geeignet und wirksam war.

Quellen