Zusammenfassung

  • Im begrenzten UDP-Beispiel von RFC 5390 konnte eine SIP-Anfrage durch drei überlastete Ziele, Proxy-Wiederholungen und Transaktionswiederholungen bis zu 18 Anfragen und ebenso viele Antworten auslösen.
  • Der 503-Mechanismus bezeichnete weder die betroffene Ressource noch die noch tragbare Menge oder den eindeutigen Geltungsbereich. Er konnte deshalb Arbeit vervielfachen, gesunde Kapazität stilllegen oder Verkehr zwischen gesättigten Servern pendeln lassen.
  • Spätere Spezifikationen trennten Monitor, Kontrollentscheidung, Feedback und vorgelagerten Aktuator. Eine Diagnose beweist keine Drosselung; eine Drosselung beweist keinen erfolgreichen Anruf.

Die Diagnose blieb am falschen Ort wirksam

RFC 3261 bot für einen lokalen Engpass einen plausiblen Ablauf. Ein Server konnte 503 zurückgeben, optional mit Retry-After, und ein Proxy durfte ein anderes Ziel wählen. Wenn nur ein Mitglied einer Farm ausgefallen war und ein zweites unabhängige Reserve besaß, wandelte dieser Mechanismus Redundanz in Verfügbarkeit um.

RFC 5390 betrachtete den Gegenfall. Die drei Ziele S1, S2 und S3 waren bereits überlastet. Der Load-Balancing-Proxy sandte zunächst an S1, wechselte nach dessen 503 zu S2 und danach zu S3. Jeder Server musste die Anfrage annehmen, auswerten, einplanen und ablehnen, obwohl keiner die eigentliche Transaktion erledigen konnte.

Die Diagnose entstand auf dem knappen Prozessor. Die Reaktion fand beim vorgelagerten Proxy statt. Dazwischen fehlte die Information, dass alle Alternativen dieselbe relevante Knappheit teilten. Der Proxy besaß eine Liste verschiedener Namen, aber keinen Nachweis verschiedener Kapazitäten.

Damit lässt sich 503 genau begrenzen. Die Antwort belegt, dass ein Verarbeitungspfad eine Anfrage nicht abschließen wollte. Sie belegt nicht, dass angebotene Last gesunken ist, dass ein anderes Ziel gesund ist, dass Warteschlangen kürzer werden oder dass ein Nutzer einen Anruf erhält. Diese Aussagen benötigen jeweils eigene Belege.

Während der Server Nein sagte, erzeugten Timer weitere Arbeit

Ein überlasteter Server antwortet nicht zwangsläufig sofort. Während er den 503 erzeugt, kann ein SIP-Client über UDP erneut senden. Das Beispiel in RFC 5390 zählt vier SIP-Transaktionen einschließlich der Strecke vom Client zum Proxy und bis zu sieben Wiederholungen je UDP-Transaktion vor dem Timeout. Unter diesen Annahmen kann eine ursprüngliche Anfrage bis zu 18 Anfragen und 18 Antworten hervorrufen.

Die Zahl ist weder eine Produktionsmessung noch ein allgemeiner SIP-Faktor. Sie gehört zu der beschriebenen Drei-Server-Topologie, zum UDP-Verhalten, zu den Timern und zum Timeout. Wer die Voraussetzungen weglässt, macht aus einer sauber begrenzten Modellrechnung eine unbelegte Behauptung.

Ihre operative Bedeutung liegt in der Kostenrechnung. Zur Ablehnung gehören die Kopien, die vor ihrem Eintreffen entstanden, und die Ausweichversuche, die sie danach auslöste. Eine Metrik, die nur ursprüngliche Eingänge zählt, kann die vom System selbst erzeugten Wiederholungen fälschlich als neue Nachfrage behandeln.

Ein zuverlässiger Transport beseitigte nur einen Multiplikator. Ohne TCP-Segmentwiederholungen entstanden im gleichen Beispiel weiterhin drei nachgelagerte Anfragen und vier Antworten. Der Transport war zuverlässiger; die Entscheidungsgrundlage des Proxys blieb unvollständig.

Ein zweiter Proxy kannte andere Namen, aber dieselben Abhängigkeiten

RFC 5390 setzte später einen weiteren Proxy über zwei Zweige. P1 hatte nach den Versuchen bei S1, S2 und S3 gelernt, dass das nachgelagerte Set überlastet war. Dieses Wissen kehrte jedoch nicht als nutzbarer Kontrollzustand mit Abhängigkeitsumfang zurück. Der obere Proxy versuchte P2, und P2 erkundete dieselben drei Server erneut.

Der logische Graph erhielt einen neuen Ast. Der Ressourcengraph erhielt keine neue Kapazität. Eine von P1 kommende Ablehnung konnte den Zustand von P1 meinen oder den Zustand des gemeinsamen Backends. Der obere Knoten konnte das nicht unterscheiden. Auch das Unterdrücken weitergeleiteter 503, um diese Verwechslung zu vermeiden, entzog dem nächsten Zweig die Information, die eine Wiederholung verhindert hätte.

Redundanz ist deshalb keine Anzahl von Endpunkten. Zwei Frontends mit derselben ausgefallenen Datenbank bilden für die betroffene Transaktion eine Fehlerdomäne. Zwei SIP-Wege, die am selben erschöpften PSTN-Gateway enden, liefern ebenfalls keine zwei unabhängigen Erfolgschancen.

Jeder Ausweichversuch braucht eine prüfbare Begründung: Welche unabhängige Ressource kommt hinzu? Ohne sie kann „alle Server versucht“ zugleich protokolltreu und systemisch verschwenderisch sein. Mehr Suchschritte sind kein Ersatz für mehr Erfolgsmöglichkeiten.

Unklarer Geltungsbereich konnte gesunde Kapazität abschalten

Dieselbe Lücke erzeugte auch das Gegenteil von Verstärkung. RFC 5390 stellte fest, dass RFC 3261 nicht eindeutig genug festlegte, ob 503 für eine IP-Adresse, einen Hostnamen oder eine URI galt. Manche Implementierungen verwendeten den Hostnamen. Wenn DNS SRV diesen Namen auf mehrere Mitglieder verteilte, konnte die Antwort eines Mitglieds den gesamten Verbund aus dem Verkehr nehmen.

Dann blieb gesunde Kapazität ungenutzt. Eine lokale Beobachtung wurde zur gruppenweiten Sperre. Übermäßiges Wiederholen und übermäßiges Abschalten wirken gegensätzlich, stammen aber aus derselben fehlenden Aussage: Der Empfänger kennt das genaue Objekt des Signals nicht.

REQ 18 von RFC 5390 verlangte deshalb einen unmissverständlichen Bezug auf IP-Adresse, Host oder URI. Der Geltungsbereich ist eine Autoritätsgrenze. Ein Server kann seinen lokalen Prozessorzustand melden. Ein allgemeiner Fehlercode ermächtigt ihn nicht, denselben Zustand für Geschwister, gemeinsame Dienste oder den gesamten DNS-Namen festzustellen.

Eine belastbare Kontrollspur hält Objekt, Beobachtungszeit, Gültigkeitsdauer, empfangenden Nachbarn und die tatsächlich gesperrte oder gedrosselte Menge fest. Eine bloße 503-Zählung lässt später nicht erkennen, ob ein kranker Knoten geschützt oder ein gesunder Cluster stillgelegt wurde.

Binäres Backoff verwandelte zwei vernünftige Knoten in einen Oszillator

Retry-After konnte einem Server Zeit zum Leeren seiner Warteschlange geben. Die Basisaktion war jedoch binär. Im Zwei-Server-Beispiel von RFC 5390 liefen S1 und S2 jeweils an der Kapazitätsgrenze. Sobald S1 eine Pause verlangte, verlagerte der Proxy den gesamten Verkehr auf S2. S2 erhielt ungefähr das Doppelte seiner Kapazität, lehnte ebenfalls ab, und nach Ablauf des ersten Timers wanderte die Last zurück.

Keine lokale Messung musste falsch sein. Die Instabilität entstand im Aktuator, der eine richtige Meldung in null oder volle Last übersetzte. Das Signal enthielt kein abgestuftes Ziel dafür, wie viel Arbeit der Server weiterhin sinnvoll übernehmen konnte.

RFC 5390 begrenzte dieses Beispiel ausdrücklich. Bei vielen unabhängigen Clients, von denen jeder nur einen kleinen Anteil liefert, kann eine selektive 503-Ausgabe eine feinere Reduktion annähern. Daraus folgt nicht, dass Retry-After in jedem Netz oszilliert. Es folgt, dass der Basismechanismus für die betrachteten Topologien keine stabile abgestufte Regelung garantierte.

REQ 7 forderte eine Reaktion auf verschiedene Überlastgrade. REQ 21 verlangte stabiles Verhalten, wenn die angebotene Last wieder unter die Kapazität fällt. Beides betrifft nicht den Wortlaut einer Fehlermeldung, sondern die Dynamik eines rückgekoppelten Systems.

Ein Code bezeichnete Ursachen mit entgegengesetzten Folgerungen

Implementierungen verwendeten 503 auch für Fehler, die keine Erschöpfung des SIP-Prozessors waren. Ein Gateway konnte genügend Signalisierungsleistung besitzen, aber keinen geeigneten PSTN-Pfad für einen bestimmten Anruf. Eine Frontend-Farm konnte gesund sein und zugleich von einer ausgefallenen Datenbank abhängen. Im ersten Fall konnte eine alternative Route helfen; im zweiten führte ein anderes Frontend zum gleichen Ausfall.

Der Proxy sah dasselbe sichtbare Zeichen in unterschiedlichen Kausalwelten. Wiederholen konnte retten oder nutzlose Arbeit vervielfachen. Nicht wiederholen konnte schützen oder gesunde Kapazität verwerfen. REQ 6 verlangte daher ein ausdrückliches Überlastsignal, das diese Ursache von anderen Fehlern trennt. REQ 8 und REQ 9 hielten beide Grenzen: bekannte oder unbekannte Überlast nicht weiter belasten, echte gesunde Ziele aber nicht blockieren.

REQ 14 verlangte zudem klare Wiederholungsanweisungen, besonders bei Verbindungsaufbau und Registrierung nach einem Neustart. Ursache, Zielobjekt, Menge und Zeit sind getrennte Dimensionen. Ein gemeinsamer Code zwingt den Empfänger sonst, fehlende Politik zu erraten.

Eine minimale gemeinsame Spezifikation muss nicht die gesamte Betriebswelt beherrschen. Sie soll eine enge, interoperable Tatsache übermitteln. Der nachgelagerte Knoten beschreibt seinen Zustand; der vorgelagerte bleibt für sein Sendeverhalten verantwortlich. Zusammenarbeit ersetzt diese Zuständigkeiten nicht.

Spätere Arbeit trennte Messen, Entscheiden, Melden und Handeln

RFC 6357 beschrieb einen geschützten SIP-Prozessor, einen Monitor, eine Kontrollfunktion, Feedback und einen vorgelagerten Aktuator. Der Monitor nimmt Proben. Die Kontrollfunktion erzeugt daraus Feedback. Der Sender setzt eine Reduktion, Verzögerung, Ablehnung oder Umleitung um, bevor überschüssige Arbeit die knappe Ressource erreicht.

Durch die Trennung werden Fehler lokalisierbar. Die Messung kann korrekt und das Feedback veraltet sein. Das Feedback kann eintreffen, während der Aktuator nichts installiert. Der Aktuator kann eine Gesamtquote erfüllen und die falschen Nachrichtenklassen verwerfen. Die Eingangsrate kann sinken, ohne dass nutzbare Arbeit zurückkehrt, wenn eine verborgene Abhängigkeit weiter ausfällt.

RFC 6357 erklärte auch, weshalb lokale Ablehnung nicht genügt: Sie verbraucht selbst Serverressourcen. Als letzte Schutzschicht ist sie sinnvoll, aber einen congestion collapse verhindert sie nicht allein. Überzählige Arbeit muss möglichst am Ursprung ihrer Zustellung begrenzt werden.

RFC 7339 transportierte später Überlastinformationen hop-by-hop in Parametern des obersten Via-Eintrags. Da der benachbarte Client diesen Via-Eintrag verbraucht, gehört das Feedback zu einer Nachbarschaftsbeziehung. oc beschrieb beim Standardverfahren eine Reduktion, oc-validity deren Lebenszeit, oc-seq die Reihenfolge und oc-algo die Verfahrensklasse. Die Felder beweisen weder die Umsetzung noch den Schutz der gesamten Anrufkette.

Verlustanteil und Ratenobergrenze versprachen Verschiedenes

RFC 7339 verlangte Unterstützung für ein loss-based Verfahren. Der Server konnte einen vorgelagerten Client auffordern, einen Anteil seiner Anfragen nicht weiterzugeben. Das war leichtgewichtig, doch der akzeptierte absolute Wert folgte der angebotenen Last: Steigt das Angebot, kann auch der verbleibende Anteil steigen.

RFC 7415 fügte optional ein rate-based Verfahren hinzu. Der Server gab einem Client eine maximale Anfragerate vor, die bis zum nächsten Update konstant blieb. Damit entstand zwischen Rückmeldungen eine Obergrenze, allerdings mit mehr Zustand und Kontrollaufwand je Client.

Keiner der Werte war ein Leistungsversprechen. Ein Maximum von 150 Anfragen pro Sekunde garantiert weder 150 abgeschlossene Transaktionen noch 150 erfolgreiche Anrufe. Nachrichtentypen können unterschiedliche Kosten haben, und der vorgelagerte Knoten entscheidet weiterhin lokal, welche davon das Budget belegen.

Die Belegkette muss daher Rückmeldewert, Sequenz und Gültigkeit, installierte Begrenzung, Angebot, Weiterleitung, ausgewählte Klassen, abgeschlossene Transaktion und Nutzerergebnis getrennt halten. Eine regelkonforme Rate kann den Prozessor schützen und dennoch Abbaumeldungen verhungern lassen, die besonders viel Zustand freigesetzt hätten.

Nutzbarer Durchsatz war die strengere Erfolgsgröße

Die erste Anforderung von RFC 5390 zielte auf useful throughput, wenn das Angebot die Kapazität weit überschreitet. Sie optimierte nicht die Anzahl erzeugter Antworten. Ein System, das jede Anfrage schnell ablehnt, ist reaktionsfähig und zugleich nutzlos.

Nutzbarer Durchsatz verbindet Zulassung mit Abschluss und Zustandsabbau. Ein BYE für einen vorhandenen Dialog kann Ressourcen freigeben; ein neuer INVITE kann weitere binden. Eine Registrierungsaktualisierung hat einen anderen Preis und eine andere Folge. Rohe Nachrichtenmengen bilden diese Unterschiede nicht ab.

Die Priorisierung blieb örtliche Politik. Betreiber konnten Notrufe, laufende Dialoge oder eigene Verpflichtungen berücksichtigen. Das gemeinsame Protokoll lieferte Feedback, wurde aber nicht zum globalen Scheduler. Wer auswählt, muss auch die Wirkung dieser Auswahl belegen.

Mit Lu Hengs Trennung der Realitätsebenen bleiben standardisierte Syntax, laufender Ressourcenzustand, Proxy-Handlung und Nutzerergebnis verschiedene Tatsachen. Erst running code setzt die spezifizierte Möglichkeit in Wirkung um. Konsens über ein Via-Feld schafft weder Prozessoren noch unabhängige Datenbanken und überträgt keine Verantwortung für falsche Prioritäten.

Evidenzgrenze

Der eingefrorene Bestand belegt den Text und den Informational-Status von RFC 5390, die dort beschriebenen Einsatzprobleme sowie die spätere Architektur in RFC 6357, RFC 7339 und RFC 7415. Er belegt keine heutige Nutzung durch einen Carrier, Hersteller oder ein Produkt. Er ordnet auch keinen realen Ausfall dem 18-Anfragen-Modell zu.

Die Zahl 18 bleibt an drei Server, UDP-Transaktionen, Wiederholungen und Timeout gebunden. Das Zwei-Server-Pendeln betrifft wenige große vorgelagerte Beziehungen, nicht jede Verteilung. Ein einzelner 503 aus einem Produktivnetz beweist außerdem nicht, dass Ressourcenüberlast die Ursache war.

Übertragbar ist ein enger Kontrollsatz: Ablehnung ist keine Reduktion. Eine belastbare Behauptung braucht die gemessene Ressource, den Kausalbereich, gültiges Feedback, vorgelagerte Handlung, örtliche Auswahl und das nutzbare Ergebnis. Fehlt ein Glied, ist nur eine gültige Fehlermeldung belegt, keine Erholung.