Zusammenfassung

  • Die SCTP-Erweiterung von 2004 trennt die Entscheidung, eine Nachricht aufzugeben, von der gemeinsamen Verarbeitung ihrer Folgen. Dafür dient FORWARD TSN.
  • Aufgegebene Daten zählen beim Sender nicht mehr als ausstehend, dürfen aber kein Wachstum des Überlastungsfensters begründen. Erledigte Buchführung ist kein Nachweis erfolgreicher Übertragung.
  • Lebensdauer, Neuübertragungslimit und Pufferpriorität steuern den Aufwand des Senders. Sie setzen beim Empfänger weder eine automatische Inhaltsfrist durch noch machen sie frühere Verarbeitung rückgängig.

Der zuverlässige Stein zwischen 104 und 106

Das Senderbeispiel in RFC 3758 beginnt bei einem tatsächlich gemeldeten kumulativen Stand von 102. Die TSNs 103 und 104 sind aufgegeben. TSN 105 ist weder bestätigt noch aufgegeben; TSN 106 ist bereits bestätigt. Gerade 105 entscheidet, was die neue Erweiterung durfte.

Der Sender berechnet neben dem wirklichen SACK-Stand einen Advanced.Peer.Ack.Point. Dieser lokale Punkt darf über 103 und 104 bis auf 104 vorrücken. Er darf nicht über den zuverlässigen, unbestätigten Stein 105 zu 106 springen. Dass hinter der Lücke ein bestätigter Block liegt, klassifiziert die Lücke nicht neu.

Das Beispiel ist keine Aufzeichnung eines Betriebsfehlers. Es ist der präzise Gegenbeweis zu einer verführerischen Abkürzung: Partielle Zuverlässigkeit bedeutet nicht, den neuesten nützlichen Block auszuwählen und alles davor abzuschreiben. Sie verlangt eine Klassifikation jeder Position, bevor ein Sprung zulässig wird.

Vier Zustände, die nicht zusammenfallen dürfen

Für die Fortschrittsentscheidung braucht der Sender einen Kontextschlüssel mit mindestens vier Bedeutungen. „Aufgegeben“ bezeichnet eine lokale, endgültige Entscheidung gegen weitere Sendeversuche. „Tatsächlich bestätigt“ stammt aus der Rückmeldung des Empfängers. „Zuverlässig und unbestätigt“ bleibt eine offene Verpflichtung. „Beim Empfänger vorhanden“ beschreibt Daten, die dort außerhalb der kumulativen Grenze liegen können.

Diese Zustände beantworten verschiedene Fragen. Aufgegebene Daten dürfen aus der Liste ausstehender Übertragungen verschwinden, doch ihre Bytes dürfen nicht als partial_bytes_acked das Überlastungsfenster vergrößern. Tatsächlich bestätigte Daten belegen Transportempfang im Umfang der SCTP-Rückmeldung, nicht die fachliche Ausführung durch eine Anwendung. Ein zuverlässiger, unbestätigter Block stoppt den Advanced.Peer.Ack.Point. Empfängerseitig gehaltene Daten können erst dann den kumulativen Stand weitertragen, wenn die Lücke vor ihnen wirklich geschlossen oder ausdrücklich überspringbar geworden ist.

Auch Fragmentierung ändert die Klasse nicht beliebig. Wird ein Fragment einer Nutzernachricht aufgegeben, müssen die zu dieser Nachricht gehörenden TSNs insgesamt aufgegeben werden. Der Sender kann nicht einen notwendigen Teil entfernen und den Rest weiterhin als Versprechen einer vollständigen Nachricht behandeln.

Erst wenn der Advanced.Peer.Ack.Point über dem tatsächlichen kumulativen SACK-Stand liegt, entsteht Anlass für FORWARD TSN. Das Steuerungselement übermittelt eine begrenzte Erlaubnis zur Zustandsänderung. Es macht den lokalen Punkt nicht rückwirkend zu einer echten Bestätigung und schreibt einem zuverlässigen Zwischenblock keine neue Eigenschaft zu.

Der Empfänger besitzt einen anderen Kontextschlüssel

Das Empfängerbeispiel des RFC darf nicht mit der Anordnung 102–106 beim Sender vermischt werden. Hier steht die kumulative Grenze ebenfalls auf 102, aber 103 fehlt, 104 und 105 sind bereits vorhanden. Später fehlt 106, während 107 gehalten wird. Ein FORWARD TSN bis 103 erlaubt zunächst den Schritt auf 103; die tatsächlich vorhandenen 104 und 105 tragen den Stand anschließend bis 105. Vor 106 endet der Fortschritt erneut.

Der neue kumulative Wert ist damit aus zwei Arten von Evidenz zusammengesetzt: autorisiertem Fehlen und tatsächlichem Vorhandensein. Er besagt nicht, dass der Inhalt von 103 nachträglich eingetroffen wäre. Ebenso wenig darf der Sender seinen Advanced.Peer.Ack.Point vor der Verarbeitung beim Empfänger als dessen wirklichen kumulativen Stand ausgeben.

Bei geordneten Nachrichten enthält FORWARD TSN zusätzlich Stream- und Nachrichtensequenzangaben. Damit kann der Empfänger spätere geordnete Nachrichten lösen, die hinter einer aufgegebenen Vorgängerin festhängen. Ungeordnete Daten gehören nicht in diese Einträge für geordnete Streams.

Der Kontext umfasst außerdem die Wiederzusammensetzung. Fehlt einer unvollständigen Nachricht noch eine TSN an oder unterhalb der neuen Grenze, muss diese Zusammensetzung entfernt werden. Hat eine teilweise Übergabe an die obere Schicht begonnen, sollte die Schicht erfahren, dass die Nachricht nicht vollständig werden wird. Ein Zahlenfortschritt ohne diese Bereinigung wäre kein korrekter Empfängerübergang.

Ein FORWARD TSN kann selbst verloren gehen. Deshalb bleibt der notwendige Neuübertragungstimer aktiv, und sein Ablauf führt erneut zur Prüfung des vorgezogenen Punkts. Ein altes oder gleiches FORWARD TSN bewegt den Empfänger nicht rückwärts; ein neues SACK kann dennoch sinnvoll sein, wenn das vorige verloren ging. Spät eintreffende, bereits übersprungene DATA-Blöcke gelten als Duplikate. Das ist keine Rücknahme dessen, was eine Anwendung vorher schon erhalten oder verarbeitet hat.

Wer darf eine Lücke überhaupt als aufgegeben markieren?

Die Antwort beginnt beim Aufbau der Assoziation. Beide Seiten signalisieren dort die Unterstützung der Erweiterung. Eine fähige Implementierung, die sie in dieser Assoziation nicht ankündigt, muss ohne sie arbeiten. Fehlt die Unterstützung des Peers, ist FORWARD TSN nicht erlaubt.

Die obere Schicht kann über diesen Fall informiert werden. Der initiierende Endpunkt kann den Aufbau abbrechen oder ohne partielle Zuverlässigkeit, also mit vollständig zuverlässigem Verhalten, fortfahren. Diese Alternative ist kein technisches Detail: Sie legt fest, ob die Anwendung einen anderen Dienstvertrag akzeptiert. Eine erfolgreiche Assoziation allein beweist nicht, dass die gewünschte Möglichkeit zum Aufgeben ausgehandelt wurde.

Die Aushandlung berechtigt allerdings noch nicht zu jedem Sprung. Sie autorisiert die gemeinsame Prozedur; die konkrete Klassifikation „aufgegeben“ muss weiterhin aus der Senderpolitik und dem Zustand genau dieser Nachricht folgen. Weder bloße Implementierungsfähigkeit noch der Wunsch, neuere Daten freizugeben, ersetzt diese Evidenz.

Lebensdauer beschreibt keine entfernte Uhr

Schon RFC 2960 enthielt eine Lebensdauer für Nutzerdaten. Lief sie ab, bevor eine erste Übertragung beginnen konnte, durfte der Transport den Auftrag verwerfen und die obere Schicht benachrichtigen. Hatte der erste Versuch rechtzeitig begonnen, blieb die Nachricht dagegen zuverlässig. RFC 4960 und RFC 9260 bewahren diese Unterscheidung der Basisschnittstelle.

Die zeitabhängige Politik des RFC 3758 erweitert die lokale Aufgabeentscheidung. Vor Vergabe einer TSN kann eine abgelaufene Nachricht verschwinden, ohne eine nummerierte Lücke zu erzeugen. Nach der Nummernvergabe braucht ihre Aufgabe die ausgehandelte Fortschrittsprozedur. Die Anwendung darf die Lebensdauer nach Übergabe an SCTP nicht ändern.

Die Implementierung muss nicht für jede Nachricht einen eigenen Timer starten oder exakt im Ablaufmoment unterbrechen. Sie kann bei Nummernvergabe, Senden, Neuübertragung oder anderen geeigneten Verarbeitungspunkten prüfen. Schon deshalb ist die Lebensdauer kein mit dem Empfänger synchronisierter Gültigkeitszeitpunkt.

Eine bereits unterwegs befindliche Kopie kann, als ausdrücklich hypothetischer Fall, vor dem FORWARD TSN eintreffen. Das Ende weiterer Senderbemühungen beweist dann weder ihre Ablehnung noch ruft es ihre frühere Verarbeitung zurück. Wer eine Inhaltsfrist beim Empfänger benötigt, braucht dort eine eigene Versions-, Zeit- oder Annahmeregel.

APIs erweiterten die Gründe, nicht die Lückenklassen

Der informative RFC 6458 beschreibt eine Socket-Schnittstelle, die zuverlässige und zeitbegrenzte Politik sowie den jeweiligen Wert unterscheidet. Daraus folgen keine überall identischen Zahlenwerte oder Voreinstellungen.

RFC 7496 ergänzt eine Grenze für Neuübertragungen. Wenn die nächste Neuübertragung eines DATA-Blocks das erlaubte Maß überschreiten würde, wird die ganze Nutzernachricht aufgegeben; schnelle und timerbedingte Neuübertragungen zählen. Der Wert null verhindert nicht den ersten Versuch, sondern führt beim Bedarf der ersten Neuübertragung zur Aufgabe. Er beweist keine erfolgreiche Einzelzustellung.

Die Prioritätspolitik desselben RFC betrifft Platz im lokalen Sendepuffer. Niedriger priorisierte Nachrichten derselben Assoziation können einer neuen weichen; zuverlässige Nachrichten stehen über den Nachrichten dieser Auswahlpolitik. Das ist weder Netzvorrang noch ein Ausführungsbefehl an den Peer. Die konkreten Eviktionsdetails bleiben implementierungsspezifisch.

Für WebRTC-Datenkanäle fordert RFC 8831 zeitbegrenzte und neuübertragungsbegrenzte partielle Zuverlässigkeit. Geordnete oder ungeordnete Übergabe bleibt davon getrennt. In diesem Aufbau liegt SCTP über DTLS und dieses über ICE/UDP. Die Anforderung ist kein heutiger Browserzensus und keine Aussage, dass jede SCTP-Nachricht dieselbe Politik trägt.

Über alle Varianten bleibt der Kontextschlüssel stabil: aufgegeben, tatsächlich bestätigt, zuverlässig unbestätigt oder beim Empfänger gehalten. Neue lokale Gründe dürfen eine Position zwischen diesen Klassen verschieben, aber sie dürfen keine zuverlässige Lücke durch Umbenennung beseitigen.

Quellen

  • RFC 2960: Lebensdauer und Beginn des ursprünglichen Sendeauftrags.
  • RFC 3758: partielle Zuverlässigkeit, FORWARD TSN und Zustandsregeln.
  • RFC 4960: spätere Basisschnittstelle.
  • RFC 6458: informative Socket-Schnittstelle für Richtlinien.
  • RFC 7496: Neuübertragungslimit, Pufferpriorität und Statistiken.
  • RFC 8831: WebRTC-Datenkanäle und Schichtenfolge.
  • RFC 9260: SCTP-Basisdienst von 2022.