Zusammenfassung

  • RFC 3322 errechnete für einen SIP/SDP-Ablauf 4.131 ms aus 9,6 kbit/s und 140 ms RTT, nannte die Näherung aber grob und ließ mögliche Wiederholungen nach Fehlern außen vor.
  • Die Zahl begründete Entwurfsanforderungen. Sie war weder Feldmessung noch Konformitätsnachweis noch Garantie, dass SigComp eine bestimmte Verbesserung lieferte.

Ein „muss“ ohne Testergebnis

Anforderungssprache klingt endgültig. Eine Lösung muss bitgenau transparent sein, mit Headerkompression koexistieren, verschiedene Transporte bedienen und darf keine spürbare Zusatzverzögerung verursachen. Doch RFC 3322 erschien im Januar 2003 als Informational und beschrieb, was eine im ROHC-Kontext zu entwickelnde Signalkompression leisten sollte. Der Text bescheinigte keinem Produkt, diese Eigenschaften erreicht zu haben.

Diese Unterscheidung ist für die technische Geschichte zentral. Eine Anforderung schafft einen Maßstab. Erst Implementierung, Test und Betrieb liefern Belege gegen diesen Maßstab. Aus dem Wort „muss“ folgt keine Verbreitung, und aus der Publikation folgt keine freiwillige Annahme durch Betreiber.

Das Ausgangsproblem war dennoch konkret. Textreiche SIP-, SDP- und RTSP-Nachrichten trafen auf Funkzugänge mit knapper Kapazität, Fehlern und vergleichsweise hohen Laufzeiten. Mehrere Anfrage-Antwort-Runden verlängerten die Aufbauphase. Fehlerkorrektur, Interleaving und ARQ machten den Kanal robuster, konnten aber Zeit hinzufügen.

Die Herkunft der 4.131 ms

RFC 3322 teilte die Bits jeder Nachricht durch 9.600 bit/s und addierte 70 ms, die Hälfte eines angenommenen RTT von 140 ms. Für den gezeigten Ablauf aus INVITE, vorläufigen Antworten, PRACK, 200 OK und ACK ergaben sich 4.131 ms. Weitere Näherungen betrafen RSVP, Sitzungsverwaltung und Funkträgeraufbau.

Der Text selbst nennt die WCDMA-Näherung „rather crude“. Verzögerungen durch mögliche Wiederholungen nach Fehlern fehlen. Es wird nur ein Mobilfunkabschnitt angenommen, das IP-Zwischennetz vereinfacht behandelt und mit typischen Nachrichtengrößen gerechnet. Auch der Vergleich von ungefähr 3,6 Sekunden bei einem GSM-Aufbau mit 7,9 Sekunden in einem SIP-Fall ist Kontext, nicht SigComp-Telemetrie.

Die Zahl ist deshalb unter ihren Bedingungen korrekt interpretierbar. Sie sagt, was Serialisierung und halber RTT in diesem Modell beitragen. Sie sagt nicht, was ein Nutzer beobachtete oder wie viel eine reale Kompression sparte. Dezimalstellen erhöhen Reproduzierbarkeit, nicht Beweisreichweite.

Transparenz statt Bedeutungsentzug

Die Alternativen zeigten, warum Kompression gewählt wurde. Höhere Datenrate pro Nutzer verringerte möglicherweise die Zahl versorgbarer Nutzer. Geringerer RTT erforderte Systemänderungen. Eine veränderte Nachrichtenfolge griff in Anwendungsprotokolle ein. Das Entfernen von Feldern verlor Transparenz und verletzte das Ende-zu-Ende-Prinzip.

Kompression durfte dagegen die Darstellung ändern, solange die dekomprimierte Nachricht bitweise identisch blieb. Die Lösung sollte beliebige Nachrichtenströme bedienen, auf unidirektionalen Pfaden ohne explizite Rückmeldung arbeiten und sowohl UDP als auch TCP unterstützen. Die Aushandlung, ob komprimiert wird, blieb ausdrücklich Sache des erzeugenden Protokolls.

Auch Robustheit war als prüfbare Zukunftsaufgabe formuliert: geringe Wahrscheinlichkeit falscher Dekompression trotz Restfehlern, minimale Fehlerfortpflanzung, spätere Nutzbarkeit nach Verlust und Toleranz gegenüber mäßiger Umordnung. Mehrere Nachrichten für bessere Kompression aufzustauen, hätte das ursprüngliche Latenzziel unterlaufen.

RFC 3320, RFC 3485, RFC 3486, RFC 4077 und RFC 5049 dokumentieren die spätere technische Linie. Sie belegen fortgesetzte Spezifikation, nicht automatisch Einsatzquote oder Leistung. Dafür braucht es Aushandlungsdaten, Versionen, Funkbedingungen, Vergleichsverkehr und Beobachtungen.

RFC 3322 blieb damit bemerkenswert diszipliniert. Ein Modell motivierte Arbeit. Anforderungen begrenzten Lösungen. Weder Modell noch Anforderungen beanspruchten die Autorität einer Messung. Erst wenn diese Trennung verloren geht, wird eine technische Zahl zu einer Legende.

Diese Trennung bleibt praktisch und überprüfbar.

Sources