Zusammenfassung

  • RFC 1989 legte den LQR-Mechanismus fest und trennte ihn ausdrücklich von der lokalen Richtlinie, die Qualität bewertet und auf schlechte Werte reagiert.
  • Kumulative Sende-, Empfangs-, Fehler- und Verwerfungszähler wurden gespeichert, zurückgemeldet und als Differenzen verglichen, sodass beide Richtungen trotz verschiedener Implementierungen beobachtbar wurden.
  • Der Bericht war kein Vertrauensanker: Richtungen wurden unabhängig ausgehandelt, 32-Bit-Zähler liefen über, Magic-Number prüfte nur Loopback, und Sicherheit sowie Wiederherstellung blieben unbestimmt.

Ein Messwert kann den Wert des Links nicht kennen

Zwei Leitungen verlieren denselben Anteil an Paketen. Die eine besitzt eine sofort verfügbare Ausweichroute und trägt zeitkritischen Verkehr. Die andere ist die einzige Verbindung eines Standorts und transportiert wiederholbare Stapeldaten. Dasselbe Messergebnis verlangt dort nicht dieselbe Handlung.

PPP Link Quality Monitoring erschien im Mai 1992 als RFC 1333. RFC 1989 löste das Dokument im August 1996 ab. Sein entscheidender Satz trennt Mechanismus und Richtlinie. PPP beschreibt Link-Quality-Report vollständig, einschließlich Zählpunkten und Verfahren. Wie ein Endpunkt Qualität beurteilt und was er bei unzureichender Qualität unternimmt, bleibt der Implementierung überlassen und darf auf beiden Seiten verschieden sein.

Diese Grenze verkleinert die notwendige Übereinstimmung. Geräte müssen sich über Bedeutung und Herkunft der Zahlen verständigen. Sie müssen weder die Kosten eines Ersatzwegs noch die Anforderungen jeder Anwendung gemeinsam besitzen. Interoperabilität endet vor der betrieblichen Wertentscheidung.

Die Aushandlung verlief in zwei Richtungen

Qualitätsüberwachung war standardmäßig ausgeschaltet. Wer Berichte empfangen wollte, setzte die LCP-Option Quality-Protocol mit Typ 4 in sein Configure-Request. Der hexadezimale Wert c025 bezeichnete Link Quality Report. Mit Configure-Ack verpflichtete sich der Peer, dieses Protokoll zu senden.

Die Verpflichtung galt in einer Richtung. Eine Anforderung bedeutete „Sende mir Berichte“, nicht automatisch „Wir senden beide“. Die Gegenrichtungen konnten unabhängig ausgehandelt werden; RFC 1661 ließ sogar unterschiedliche Qualitätsprotokolle je Richtung zu. Wer LQR-Sendung akzeptierte, musste dennoch eingehende LQR korrekt verarbeiten, selbst ohne eigene Anforderung oder Bewertungsrichtlinie.

Für LQR enthielt die Option eine vier Oktette lange Reporting-Period in Hundertstelsekunden. Sie setzte den größten Abstand zwischen Berichten; schnelleres Senden war erlaubt. Null bedeutete, ohne eigenen Timer unmittelbar auf einen eingehenden LQR zu antworten. Die Aushandlung verhinderte, dass beide Seiten Null wählten und ewig auf den ersten Bericht warteten.

Ein Protocol-Reject für LQR beendete die Sendepflicht. Das aufgezeichnete Ack belegt somit eine damalige Vereinbarung, aber weder spätere Zustellung noch eine daraus abgeleitete Ausfallentscheidung.

Der Empfänger ergänzte, was nie über die Leitung kam

LQR-Feldnamen beziehen sich auf den Empfänger, weil er den Bericht angefordert hat. PeerOutPackets, PeerOutOctets und PeerOutLQRs sind die aktuellen Ausgangszähler des Senders. Beim Empfang fügt der lokale Prozess logisch SaveInPackets, SaveInOctets, Verwerfungen, Fehler und SaveInLQRs hinzu. Diese SaveIn-Werte wurden nicht auf dem eingehenden Link übertragen; sie stammen vom lokalen Messpunkt.

In einem späteren Bericht in Gegenrichtung kehren die gespeicherten Beobachtungen als PeerIn... zurück. LastOut... kopiert die zuletzt empfangene Sicht auf frühere lokale Ausgangswerte. Die Berichtsfolge trägt dadurch nicht nur die Behauptung „so viel habe ich gesendet“, sondern auch die zeitversetzte Antwort „so viel sah die andere Seite ankommen“.

Die Abstimmung arbeitet mit Differenzen kumulativer Zähler. Änderungen von PeerInPackets gegenüber LastOutPackets schätzen Verluste in lokaler Ausgangsrichtung. SaveInPackets gegenüber PeerOutPackets beleuchtet den Eingang. Oktette bilden eine weitere Dimension. Zunehmende Verwerfungen und Fehler beim Peer können auf Überlastung des Empfängers statt auf einen physischen Leitungsfehler hindeuten.

Sie können darauf hindeuten; sie beweisen es nicht. LQR stellt keine signierte Quittung pro Paket aus und beglaubigt die Aussagen des Peers nicht.

Eine gemeinsame Zähleinheit war Teil des Protokolls

PPP-Framing konnte in einem Softwareprozess, in mehreren Prozessen oder in Hardware stattfinden. Ein Konverter konnte Escape-Darstellungen unsichtbar verändern. Würde jedes Produkt seinen nächsten Hardwarezähler melden, sähe der Unterschied zwischen Darstellungen wie Paketverlust aus.

RFC 1989 definierte deshalb einen abstrakten Bezug. Gezählt werden alle vom FCS erfassten Oktette, das FCS selbst und ein Flag-Oktett pro Frame. Weitere Flagfolgen sowie Escape-Bits oder -Oktette zählen nicht. Gemeint ist eine reproduzierbare Informationsmenge, nicht die gesamte physische Bandbreitennutzung. InGoodOctets schließt Frames aus, die als verworfen oder fehlerhaft gelten.

Beim Einsetzen der Werte ist der erwartete Beitrag des gerade erzeugten LQR bereits einzurechnen. Die Zähler steigen, doch ihre 32-Bit-Felder laufen schließlich auf Null über. Differenzberechnungen müssen den Überlauf behandeln. Einige Schnittstellenzähler starten beim LCP-Aufbau zudem nicht an einem gemeinsamen Wert. Synchronität entsteht durch relative Änderungen, nicht durch ein angenommenes gemeinsames Null.

Falsch gezählte Escape-Oktette erzeugen lastabhängige Scheindifferenzen. Ein Überlauf als gewöhnliche vorzeichenbehaftete Subtraktion erzeugt ein unmögliches Ereignis. Gleiche Feldbreite genügte nicht; entscheidend war die gleiche Semantik.

Ein fehlender Bericht war noch keine Entscheidung

LQR erhielt im Multiplexer höchste Priorität, damit die Qualitätsinformation nicht hinter Nutzverkehr wartete. Häufiger war trotzdem nicht immer besser. Auf einem guten Link ist der Bericht überflüssig und sollte aktive Daten möglichst wenig stören. Ein längeres Intervall glättet kurze Ausschläge, verzögert aber die Erkennung eines Totalausfalls.

Asymmetrische Verluste widersprechen einfacher Timerlogik. Treffen Eingangsberichte ein und zeigen eine sehr schlechte Ausgangsrichtung, hilft schnelleres lokales Senden kaum, weil die zusätzlichen Berichte genau dort verloren gehen. Ist der Ausgang gut und der Eingang schlecht, können mehrere Versuche wenigstens einen Bericht durchbringen und dem Peer eine eigene Bewertung ermöglichen.

RFC 1989 verlangte nach einem ausgebliebenen oder wirklich schlechten Bericht mindestens einen weiteren Versuch. Eine algorithmische Entscheidung benötigte wenigstens zwei Umlaufzeiten. Kurzzeitige Last oder der Verlust des Berichts selbst konnten das erste Signal erklären.

Hysterese wurde empfohlen; K Erfolge aus N Perioden war ein Beispiel. K, N und Grenzwert wurden nicht zum Protokoll. Auch die Erholung blieb offen. NCPs zu schließen, LQR weiterzusenden und später neu zu konfigurieren war ein Vorschlag. Routenwechsel, Trennung oder Weiterbetrieb waren lokale Alternativen.

c025 bestätigte keine Identität

War Magic-Number ausgehandelt, konnte die eigene Nummer in einem eingehenden LQR einen zurückgeschleiften Link anzeigen. Ohne Aushandlung stand Null im Feld und wurde ignoriert. Das half bei einer Datenlink-Anomalie, authentisierte aber weder Gerät noch Betreiber.

RFC 1989 erklärt, Sicherheitsfragen würden nicht behandelt. Der Bericht erhielt weder kryptographische Integrität noch einen unabhängigen Nachweis für seine Zähler. PPP-Authentisierung gehörte in eine andere Phase. c025 an einem Beobachtungspunkt beweist dort eine LQR-Darstellung; es beweist nicht die Wahrheit der Werte oder die Zustellung an eine Anwendung.

Ein Betriebsprotokoll muss Configure-Request, Ack oder Reject, Reporting-Period, tatsächliche Ankünfte, Rohzähler, Überlaufkorrektur, Differenzen, Richtlinienversion und Folgeaktion getrennt erhalten. Ein einzelner Zeitstempel „Link schlecht“ entfernt den Urheber des Urteils.

Gemeinsame Belege, getrennte Entscheidungen

LQR ist historisch interessant, weil sein Konsens nicht größer wurde als nötig. Anforderung, maximale Berichtszeit, Messpunkte, Rückgabe beider Richtungen und Differenzsemantik waren gemeinsam. Akzeptabler Verlust und tragbare Wiederherstellungskosten waren es nicht.

Zwei Endpunkte konnten unterschiedliche Fenster, Schwellen und Reaktionen betreiben und trotzdem denselben Bericht verstehen. Lokale Verbesserungen brauchten keine zentrale Erlaubnis; sie mussten nur den freiwillig ausgehandelten Mechanismus einhalten.

Die IANA-Zuweisung c025 belegt den Protokolltyp. Configure-Ack belegt die angenommene Berichtspflicht. Zählerdifferenzen stützen eine Schätzung, Fehler und Verwerfungen verengen die Hypothese. Erst eine lokale Richtlinie erzeugt den Status; erst Routing-, NCP-, Link- und Anwendungsbelege zeigen die Wirkung.

Der Bericht machte Meinungsverschiedenheiten messbar. Er durfte sie nicht durch ein universelles Urteil ersetzen.

Quellen