Zusammenfassung

  • RFC 3320 führte für jede Signalisierungsnachricht eine eigene, begrenzte virtuelle Dekompressionsmaschine aus – auch wenn der Sender das auszuführende Programm mitlieferte.
  • Eine erfolgreiche Dekompression berechtigte noch nicht zu dauerhaftem Zustand: Erst wenn die Anwendung das Ergebnis authentifizierte und eine gültige Kennung für ein Compartiment lieferte, durfte neuer Zustand gespeichert oder Rückmeldung weitergegeben werden.

Mit der Kompression reiste auch ein Programm

Die im Januar 2003 veröffentlichte RFC 3320 beschreibt Signaling Compression, kurz SigComp, für Anwendungsprotokolle wie SIP und RTSP. Sie setzt nicht voraus, dass alle Kommunikationspartner denselben Kompressor vorab installiert haben. Der Sender kann ein Verfahren auswählen und bei Bedarf Bytecode mitschicken, den die Universal Decompressor Virtual Machine (UDVM) des Empfängers ausführt. Der Empfänger musste dadurch neue Dekompressionslogik akzeptieren können, ohne einem entfernten Absender freie Kontrolle über den eigenen Rechner zu geben.

Die historische Frage lautet also nicht nur, wie viele Bytes eine Kompression spart. Sie lautet auch: Welche Berechnung kann eine eingehende Nachricht auslösen, und welche Erinnerung darf sie beim Empfänger hinterlassen? Die RFCs belegen weder eine breite Einführung von SigComp noch konkrete Einsparungen im Betrieb. Sie definieren eine Protokollgrenze: Der Sender darf eine begrenzte Berechnung beeinflussen; die Kontrolle über Ressourcen und über nachrichtenübergreifenden Speicher bleibt beim Empfänger.

Für jede Nachricht beginnt eine neue Ausführung

Jede empfangene SigComp-Nachricht startet eine eigene UDVM-Instanz. Der Dekompressionsspeicher ist pro Nachricht begrenzt; jeder Endpunkt muss dafür mindestens 2.048 Byte bereitstellen. Auch die Zahl der Instruktionen hängt von Nachrichtenlänge und cycles_per_bit ab: Für n Byte gilt als Höchstwert (8*n + 1000) * cycles_per_bit, wobei der Parameter mindestens 16 beträgt. Das sind Grenzen je Ausführung. Sie sind weder eine vollständige Formel für die Gesamtlast eines Servers noch eine Garantie gegen alle Formen von Denial of Service.

Eine frische Instanz schafft eine Fehlergrenze. Ist eine Nachricht fehlerhaft oder verbraucht sie ihr Instruktionsbudget, muss die nächste gültige Nachricht nicht in derselben virtuellen Maschine feststecken. Der Empfänger braucht keinen einzelnen Stromdecoder, dessen Zustand unbegrenzt wächst. Die Spezifikation macht einen Neustartpunkt sichtbar, erlaubt aber zugleich, ausgewählten Zustand zwischen Nachrichten zu teilen. Ausführungsgrenze und persistenter Speicher sind zwei verschiedene Mechanismen.

Dekomprimieren und Behalten sind getrennte Berechtigungen

SigComp unterscheidet den temporären Dekompressionsspeicher vom Zustandsspeicher, der einem Compartiment zugewiesen ist. Die Anwendung definiert solche Compartiments für einen Kommunikationskontext und kann sie schließen, wenn dieser endet. Ein Endpunkt, der nichts dauerhaft behalten will, kann eine Zustandskapazität von null festlegen. Persistenz ist somit keine Voraussetzung, um die aktuelle Nachricht zu dekodieren.

Die wichtigere Regel greift nach der Dekompression. Die Anwendung erhält die rekonstruierte Nachricht und kann sie passend zu Protokoll und Kontext authentifizieren. Nur wenn sie der Nachricht eine gültige Compartiment-Kennung zuordnet, darf die SigComp-Schicht neuen Zustand für dieses Compartiment anlegen und Rückmeldung an den Kompressor weiterreichen. Reicht das Vertrauen nicht aus, gibt die Anwendung keine gültige Kennung zurück. Die UDVM endet dann, ohne den angeforderten Zustand zu speichern oder die Rückmeldung weiterzuleiten.

Die semantische Entscheidung liegt damit außerhalb des Decoders. Die virtuelle Maschine kann feststellen, dass sie innerhalb ihrer Grenzen Bytes erzeugt hat. Sie kann aber nicht entscheiden, ob die Signalisierung authentisch ist, zum erwarteten Dialog gehört oder künftige Kompression beeinflussen soll. Diese Fragen kann die Anwendung besser beurteilen und behält deshalb das letzte Wort. RFC 4896 präzisierte später die Verbindung zwischen Authentifizierung und Zustandserzeugung: Die Ausgabe des Decoders ist noch keine Vertrauensentscheidung.

Der Zugriff auf vorhandenen Zustand folgt einer anderen Schranke

Es gibt ein Reihenfolgeproblem: Vielleicht braucht die Anwendung erst die dekomprimierte Nachricht, um sie zu authentifizieren, während die Dekompression vorhandenen Zustand verwenden möchte. SigComp behandelt den Zugriff auf bestehenden Zustand getrennt von der späteren Anwendungsfreigabe. Zustandskennungen werden aus einem Hash der Zustandsbytes abgeleitet; der Empfänger prüft die Kennung, bevor er den Zustand für die UDVM verfügbar macht. Auch ein erlaubter Lesezugriff ersetzt nicht die spätere Freigabe, neuen Zustand zu behalten.

„Darf diese Nachricht einen bereits eingerichteten Kompressionszustand lesen?“ und „Darf der authentifizierte Inhalt dauerhaften Zustand schaffen oder verändern?“ sind unterschiedliche Fragen mit unterschiedlichen Nachweisen. Werden sie vermischt, wirken die Regeln widersprüchlich. Tatsächlich ermöglicht die erste Schranke eine kontrollierte Dekompression; die zweite wartet auf die Bewertung des Inhalts durch die Anwendung.

Spätere Dokumente schlossen benachbarte Lücken

RFC 3321 ergänzte erweiterte Operationen und Bestätigungsmechanismen; bei unzuverlässigen Transporten muss eine Bestätigung berücksichtigt werden, bevor der Sender auf entfernten Zustand baut. RFC 4077 beschreibt negative Bestätigungen für Dekompressionsfehler. RFC 5049 formuliert SigComp-Anforderungen speziell für SIP; sie dürfen nicht auf jede Anwendung übertragen werden. RFC 4464 ist ein Leitfaden, RFC 4465 eine Sammlung anspruchsvoller Tests. Diese Texte ergänzen Erklärung, Fehlerbehandlung und anwendungsspezifische Profile, beweisen aber für sich genommen weder Einführung noch gemessenen Nutzen.

Der nachhaltige Beitrag der RFC 3320 ist die geteilte Zuständigkeit. Eine Nachricht darf eine begrenzte Berechnung anfordern. Die Anwendung entscheidet, ob deren Bedeutung vertrauenswürdig genug ist, um Erinnerung für spätere Nachrichten zu werden. So bleiben Ressourcengrenze und Vertrauensgrenze sichtbar; aus „dekomprimiert“ wird nicht stillschweigend „gespeichert“.

Quellen