Zusammenfassung

  • OC-Reduction-Percentage = 100 fordert nach RFC 7683 Behandlung für sämtliche passenden neuen Anfragen, die der reagierende Knoten sonst senden würde; eine absolute Abnahme des Verkehrs garantiert der zustandslose Algorithmus ausdrücklich nicht.
  • Eine belastbare Betriebsaussage muss den exakten OLR mit dem angenommenen OCS, den Entscheidungen je Anfrage sowie gemessenem Verkehr und Nutzdurchsatz unter gleichen Identitäten, Geltungsbereichen und Zeitfenstern verbinden.

Der Prozentwert steht vor dem Ergebnis

Eine „hundertprozentige Reduktion“ klingt nach einem Vergleich von Vorher und Nachher. Beim Diameter Overload Indication Conveyance, kurz DOIC, wird sie vor der Wirkung ausgesprochen. RFC 7683 beschreibt OC-Reduction-Percentage als den Anteil des Verkehrs, den ein Sender gegenüber dem ohne Maßnahme vorgesehenen Volumen reduzieren soll. Der Wert 100 verlangt Behandlung des gesamten erfassten Verkehrs, weil der meldende Knoten schwer belastet ist und keine neuen Nachrichten verarbeitet.

Der OLR beweist damit eine eindeutige Steuerungsabsicht. Er ist aber weder Eingangszähler noch Empfangsbestätigung aller Teilnehmer. Er sagt nicht, dass jeder Client DOIC unterstützt, jeder reagierende Knoten dieselbe Zustandsversion übernommen hat oder umgeleitete Anfragen aus dem Gesamtsystem verschwunden sind. Wer daraus „Verkehr gleich null“ macht, wechselt unbemerkt vom Befehl zur Beobachtung.

Ben Campbells IETF-Arbeit verläuft genau durch diese Trennlinie. Sein Datatracker-Profil nennt Tätigkeiten in der Echtzeitkommunikation sowie frühere Rollen im IAB, als ART Area Director und als Vorsitzender mehrerer Arbeitsgruppen. Campbell ist Mitautor von RFC 7068 zu Überlastanforderungen, RFC 7683 zum DOIC-Mechanismus und RFC 8583 zur Übermittlung von Lastinformationen. Die Dokumente teilen eine Methode: Jeder Zahlenwert wird an den Knoten und die Entscheidung gebunden, die er tatsächlich beschreibt.

Melden und Reagieren sind getrennte Rollen

Der meldende Knoten erkennt die Überlast und bestimmt mit einem implementationsabhängigen Verfahren die benötigte Reduktion. Er sendet einen Overload Report, OLR. Der reagierende Knoten empfängt ihn, führt einen Overload Control State, OCS, und wählt die einzelnen Anfragen aus, die behandelt werden. Auch diese Auswahl bleibt der Implementierung überlassen.

Beim voreingestellten Loss-Algorithmus muss der reagierende Knoten den verlangten Anteil neuer Anfragen der Abatement-Behandlung zuführen. RFC 7683 zieht danach eine klare Grenze: Weil der Algorithmus zustandslos ist, garantiert er keine absolute Verringerung des gesendeten Verkehrs. Garantiert wird, dass der verlangte Anteil neuer Anfragen ausgewählt wird.

Behandlung bedeutet nicht zwingend Verwerfen. Anwendungsregeln können eine Anfrage drosseln oder zu einem anderen Ziel umleiten. RFC 8581 bevorzugt bei einem Peer Overload Report die Umleitung und verlangt Drosselung, wenn alternative Peers nicht genügend Kapazität besitzen. Der geschützte Knoten kann weniger Eingänge sehen, während ein Nachbarknoten mehr Last übernimmt oder Anwendungen mit Fehlern und Wiederholungen reagieren. Das sind verschiedene Messgrößen.

Hundert Prozent wovon?

RFC 7683 unterscheidet Host Report und Realm Report. Der eine gilt für host-geroutete, der andere für realm-geroutete Anfragen; die Application-ID gehört zur Zustandszuordnung. RFC 8581 ergänzt für überlastete Diameter Agents den Peer Report, der über Application-ID und Diameter-Identität des Peers abgegrenzt wird.

„Alle“ meint folglich alle Anfragen, die zu diesem aktiven OCS passen. Andere Anwendungen, Hosts, Realms oder Peers können außerhalb liegen. Ein nicht unterstützender Client besitzt den Zustand möglicherweise gar nicht. Beim Peer Report muss der reagierende Knoten einen Bericht ignorieren, wenn dessen SourceID nicht mit der Identität des Peers übereinstimmt, von dem die Antwort kam. Herkunft ist somit Teil der Steuerungsberechtigung.

Zeit und Reihenfolge gehören ebenfalls zum Zustand. Eine höhere OC-Sequence-Number aktualisiert einen passenden OCS; eine gleiche oder kleinere wird ignoriert. Änderungen an Gültigkeitsdauer oder Reduktionsparametern erfordern eine neue Nummer. Solange frühere Berichte noch gültig sind, muss die Reihenfolge sogar einen Neustart des meldenden Knotens überstehen. Für die Rekonstruktion zählt daher nicht nur die zuletzt gesendete Zahl, sondern die Version, die jeder reagierende Knoten beim Bearbeiten einer Anfrage akzeptiert hatte.

Ein fehlender OLR beendet nichts

In vielen Oberflächen bedeutet ein verschwundenes Warnfeld Entwarnung. DOIC definiert es anders. Eine Antwort ohne OC-OLR löscht den OCS nicht; die Abwesenheit bedeutet „keine Änderung“. Der meldende Knoten kann das Ende mit einer Gültigkeitsdauer von null signalisieren, oder der Zustand läuft nach seiner gespeicherten Dauer aus.

Auch danach soll der Verkehr nicht schlagartig zurückkehren. RFC 7683 empfiehlt beim Austritt aus einer hundertprozentigen Reduktion ein vorsichtiges Hochfahren, etwa mit Probe-Nachrichten, damit der Knoten nicht sofort wieder in Überlast gerät. RFC 8581 fordert auch für Peer-Zustände ein kontrolliertes Ende. Explizites Ende, lokaler Ablauf, erneute Sendung und messbare Diensterholung sind deshalb vier mögliche Zeitpunkte.

Eine Incident-Timeline, die die erste Antwort ohne OLR als Wiederherstellung markiert, liest die Zustandsmaschine falsch. Wer allein den Ablauf des OCS als Leistungsbeleg nimmt, ersetzt Beobachtung durch Verwaltungslogik.

Mehrere Berichte sind keine Prozentrechnung

Host-, Realm- und Peer-Berichte können in derselben Nachricht auftreten. Nach RFC 8581 behandelt der reagierende Knoten zunächst Host oder Realm. Erst die verbleibenden Nachrichten durchlaufen die Peer-Abatement-Behandlung; bereits reduzierte Mengen sollen berücksichtigt werden, um Schwingungen zu vermeiden.

Die Prozentsätze sind also keine unabhängigen Verlustanzeigen. Ihre Addition oder die Anwendung jedes Werts auf die ursprüngliche Menge erfindet einen gemeinsamen Nenner. Ein Audit braucht aufeinanderfolgende Mengen: Kandidaten, Treffer im Host- oder Realm-OCS, verbleibende Anfragen, Treffer im Peer-OCS sowie Umleitungen, Drosselungen und normale Sendungen. Erst daraus werden steuernde Prozente zu nachvollziehbaren Stückzahlen.

Last und Überlast drehen die Skala um

RFC 8583 trennt eine ständig vorhandene Last von einem außergewöhnlichen Überlastzustand. Ein Load Report liefert einen Hinweis für Verteilung oder Prognose. Ein OLR verlangt ausdrücklich eine Verringerung der offered load und wirkt wie ein Vertrag zwischen meldendem und reagierendem Knoten.

Die Werte laufen in entgegengesetzte Richtungen. Bei Diameter Load bedeutet eine hohe Zahl geringere tatsächliche Last: 65535 steht für null Last, 0 für hundertprozentige Last. Bei OC-Reduction-Percentage bedeutet 0, dass keine Abatement-Maßnahme nötig ist, während 100 die Behandlung aller passenden Anfragen verlangt. Eine gemeinsame Datenbankspalte „Prozent“ kann die Bedeutung umkehren, ohne einen Syntaxfehler zu erzeugen.

RFC 7068 nennt den gesamten Nutzdurchsatz unter Last als letztliche Wertmessung einer Lösung. Er muss beobachtet werden. Der OLR belegt die Aufforderung, der OCS den angenommenen Zustand, das Auswahlprotokoll die Behandlung, Zähler die Ankünfte und Anwendungstelemetrie die erledigte Arbeit. Kein früheres Glied ersetzt das spätere.

Eine Beweiskette für die Nachanalyse

Am Anfang steht die Meldeentscheidung: Knotenidentität, Application-ID, Berichtstyp, Implementierungsversion der Berechnung und Zeitpunkt. Danach wird der genaue OLR mit Sequenz, Gültigkeit, Algorithmus, Prozentwert und Sendezeit erhalten.

Jeder reagierende Knoten benötigt eine eigene Empfangsspur. Hatte er Unterstützung angekündigt? Akzeptierte er die Quelle? Erzeugte oder aktualisierte die Sequenz seinen OCS, oder wurde sie als alt verworfen? Für welchen Zeitraum galt der Zustand lokal? Die Entscheidung zu jeder passenden Anfrage muss auf diesen OCS verweisen und normale Weiterleitung, Umleitung oder Drosselung benennen.

Erst auf dieser Grundlage lassen sich Eingänge am geschützten und an alternativen Knoten, die vorgesehene Ausgangsmenge, Ablehnungen, Wiederholungen, Nutzdurchsatz und Anwendungsergebnis im selben Zeitfenster vergleichen. Fehlt ein Glied, endet dort auch die Aussage. „Knoten A hielt einen OCS mit 100 %“ kann wahr sein, während „der Verkehr war null“ ungeklärt bleibt.

Quellen