Zusammenfassung

  • RFC 9616 misst RTT zwischen Babel-Nachbarn mit lokalen Zeitdifferenzen; synchronisierte Uhren sind nicht erforderlich.
  • Empfohlen werden exponentielle Glättung mit Alpha 0,836, eine begrenzte Kostenabbildung mit 10/120 ms und maximaler Strafe 150 sowie Hysterese.
  • Diese Werte schaffen Stabilität, vernichten aber absichtlich Unterschiede. Niedrigere Routingkosten sind deshalb kein Beleg für bessere Ende-zu-Ende-Leistung.

Die Grafik in RFC 9616 hat zwei flache Bereiche. Unterhalb von rtt-min bleibt der Link beim nominellen Wert C. Oberhalb von rtt-max steigt die Zusatzstrafe nicht weiter. Nur dazwischen reagiert der Kostenwert linear auf Verzögerung.

Diese Form verhindert, dass geringe Schwankungen eines schnellen Links oder extreme Werte eines schlechten Links die Route ständig bewegen. Sie ist zugleich ein Filter über die Wirklichkeit. Mit den empfohlenen 10 ms sind 1 und 9 ms gleich. Mit 120 ms als Obergrenze sind 130 und 600 ms gleich stark bestraft.

Wer die Werte übernimmt, hat nicht auf eine Entscheidung verzichtet. Er hat die Annahme übernommen, dass die ausgelöschten Unterschiede für sein Netz entbehrlich sind.

Das Tunnelproblem

RFC 8966 schreibt Babel keinen einzigen Metrikalgorithmus vor. Paketverlust kann im Funknetz sinnvoll sein, Hop Count in anderen Netzen. In Tunneln verliert Hop Count jedoch räumliche Bedeutung.

Das RFC-Beispiel setzt A, B und D nach Paris und C nach Tokio. Von A nach D gibt es zwei gleich lange Hop-Pfade. Der lokale Weg über B und der entfernte über C sehen gleich aus, obwohl der zweite wahrscheinlich höhere Verzögerung und Kosten verursacht. Eine formal korrekte Abstraktion hat die entscheidende Beobachtung verloren.

RFC 9616 ergänzt Zeitstempel in Hello und IHU. A sendet t1; B notiert t1', gibt beide Werte zurück und sendet ein neues Hello mit t2'. Beim Empfang t2 berechnet A RTT = (t2 - t1) - (t2' - t1').

Jede Differenz entsteht innerhalb einer lokalen Uhr. Gemeinsame Zeitbasis ist unnötig. Die Methode geht auf Mills und RFC 891 zurück; RFC 5905 liefert verwandten Zeitkontext.

Im IANA-Register für Babel ist Timestamp Typ 3. Hello trägt vier, IHU acht Oktette. Der gemeinsame Drahtmechanismus bleibt klein. Die Deutung wird nicht zentralisiert.

Messstelle vor Formel

Der Sendezeitpunkt soll unmittelbar vor Übergabe an den Netzwerk-Stack entstehen, der Empfangszeitpunkt unmittelbar danach. Ein früherer oder späterer Punkt rechnet lokale Queue- und Scheduling-Zeit dem Link zu. Deshalb empfiehlt das RFC, zunächst PadN einzusetzen und erst direkt vor dem Senden zu überschreiben.

Konformes Format beweist also nicht identische Messoberfläche. Für Vergleichbarkeit braucht man Implementierung, Softwarestand, Clock und Instrumentierungsstelle.

Die 32-Bit-Mikrosekundenzähler laufen nach rund 71 Minuten über. Neustarts wählen einen neuen Ursprung. Ein empfohlenes Drei-Minuten-Fenster verwirft zukünftige, veraltete oder widersprüchliche Samples. Nachbarschaft kann bestehen bleiben, während ein Sample unbrauchbar ist.

Eine geglättete Linie ohne Alter, Annahmequote und Neustartmarke ist unvollständige Evidenz. Sie kann Ruhe anzeigen, weil kaum noch gültige Beobachtungen eintreffen.

Warum der Rohwert nicht entscheiden darf

Bursts erzeugen Spitzen. Zwei ähnliche Pfade kreuzen sich. Außerdem verändert Routing den Messwert: Ein niedriger RTT zieht Verkehr an, Verkehr erzeugt Queue, der RTT steigt, der Pfad verliert, entlastet sich und gewinnt erneut. Ohne Bremse erzeugt die Regel ihren eigenen Wechsel.

Die Primärstudie A delay-based routing metric berichtet keine Oszillation in realen Tests, aber Minutenperioden in konstruierten ungünstigen Szenarien. Das ist Beleg für den Entwurf unter geprüften Bedingungen, kein Universalsatz.

Die erste Bremse ist RTT := α RTT + (1 - α) RTTn. Alpha soll 0,8 bis 0,9 betragen; 0,836 ist die Empfehlung. Vergangenes erhält Gewicht. Ausreißer wirken weniger, echte Änderungen später.

Die zweite Bremse ist die begrenzte Abbildung mit 10 ms, 120 ms und maximal 150 Zusatzkosten als empfohlenem Startpunkt. Die dritte ist Hysterese, damit kleine Bewegungen im linearen Bereich die Route nicht laufend ersetzen.

Das Ergebnis ist nicht „gemessene Latenz“, sondern ein aus Messung, Gedächtnis, Grenzwerten und Wechselregel erzeugtes Steuersignal.

Parameter brauchen eine Haftungskette

rtt-min bestimmt, welche niedrigen Unterschiede unwichtig sind. rtt-max bestimmt, ab wann weitere Verschlechterung nicht mehr differenziert wird. max-rtt-penalty bestimmt das Gewicht gegenüber nominellen Linkkosten.

Ein niedrigeres Maximum stabilisiert, reduziert aber die Auswahl unter schlechten Pfaden. Ein höheres Maximum erhält Unterschiede und lässt mehr Bewegung zu. Keine Einstellung misst automatisch Bandbreite, Verlust, Preis, Verfügbarkeit oder Anwendungswert.

Der Betreiber muss Ziel und Verantwortlichen benennen: Soll nur ein interkontinentaler Umweg vermieden werden? Muss ein Dienst einstellige Millisekunden unterscheiden? Wie lange darf eine alte Auswahl bestehen? Wann darf Anwendungsbeobachtung die Routingannahme überstimmen?

Ohne diese Antworten wird ein Default zur herrenlosen Policy.

Zeitliche Schuld der Hysterese

RFC 9616 warnt, dass das Verfahren nach RTT-Änderungen Sekunden oder Minuten suboptimal bleiben kann. In festen Overlays ist das oft günstiger als Flapping und Paketumsortierung. Bei hoher Mobilität kann es eine verschwundene Topologie konservieren.

Wenig Routenwechsel beweisen Stabilität, nicht Richtigkeit. Tests müssen Übergänge erzeugen: Propagation ändern, Kapazität separat reduzieren, Last hinzufügen, einen Nachbarn neu starten, Überlauf abwarten, einen Knoten bewegen. Dann Sample, Glättung, Kosten, Auswahl, FIB und erstes Paket zeitlich verbinden.

Der Nachbar-RTT bleibt ein Linksignal. Spätere Queues, Verluste, Serverarbeit und Anwendungsketten liegen außerhalb. Selbst perfekte Linkmessung ist nur ein Prädiktor.

Mischbetrieb als bewusste Unschärfe

Alte Implementierungen ignorieren unbekannte sub-TLVs. Neue und alte Router können zusammenarbeiten, ohne durch diese Mischung Schleifen oder Pathologien zu erzeugen; suboptimale Routen bleiben möglich.

Das schützt freiwillige schrittweise Einführung. Es schafft keine einheitliche Semantik. RTT, Hop Count und Verlust können im selben Pfad zusammenkommen. Fähigkeit ist je Adjazenz zu inventarisieren, nicht als Flottenprozent.

Tests müssen Grenzen belasten: alter Knoten wird Transit, neuer Knoten unterdrückt Timestamp, ein Pfad wechselt zwischen Metrikinseln. Rückwärtskompatibilität ist Betriebsfortsetzung, keine Ergebnisgarantie.

RFC 9647 behandelt daneben die YANG-Sicht auf Babel. Sichtbarer Zustand ist nicht identisch mit korrekter Messherkunft, Parameterwahl oder Zustellung.

Datenschutz ändert die verfügbare Evidenz

Der willkürliche Uhrursprung verrät nicht direkt Bootzeit oder Zeitzone. Präzise Zeitinformationen können dennoch physische Lokalisierung erleichtern. Ein Knoten darf Timestamp weglassen; Nachbarn fallen auf Hop Count zurück.

Ablehnung ist Teil des Designs. Sie schützt eine Oberfläche und verändert die Routeninformation. Dokumentiert werden müssen Interface, Bedrohung, Ersatzmetrik und Wirkung. Weder darf Verzicht automatisch als Fehler gelten, noch darf sein Einfluss unsichtbar bleiben.

So bleibt die gemeinsame Schicht dünn: interoperabler Mechanismus, lokale Einführung, lokale Ablehnung und beobachtbare Folgen statt zentraler Pflicht.

Die Beweiskette

Erstens: Zeitprovenienz — Implementierung, Messstelle, Uhr, Überlauf, Neustart, angenommene und verworfene Samples. Zweitens: Transformation — Alpha, Schwellen, Strafe, nominelle Kosten und Hysterese.

Drittens: Entscheidung — Kandidaten, berechnete Kosten, Auswahlgrund und Beruhigungszeit. Viertens: Ausführung — RIB, FIB, Next Hop, Paketpfad, Verlust. Fünftens: Dienst — Latenzverteilung, Durchsatz, Abschluss und sichtbarer Fehler.

Ein niedrigerer Kostenwert belegt nur die lokale Berechnung. Eine Dienstverbesserung verlangt alle folgenden Quittungen.

Quellen