Zusammenfassung

  • RFC 3758 überließ den Abbruchzeitpunkt einer Dienstpolitik und definierte FORWARD TSN als allgemeines Mittel, die Sequenz fortzusetzen.
  • Auch bei zeitbegrenzter Zuverlässigkeit muss der SCTP-Stack eine Nachricht nicht zwingend exakt in der Sekunde ihres Fristablaufs prüfen.

Die Frist war abgelaufen. Der SCTP-Stack durfte trotzdem später nachsehen. RFC 3758 behandelte den Ablaufzeitpunkt und den Zeitpunkt, an dem eine Implementierung ihn bemerkt, als zwei verschiedene Dinge.

Die Erweiterung machte SCTP nicht pauschal unzuverlässig. Sie gab der oberen Schicht die Möglichkeit, für jede Nachricht festzulegen, wie ausdauernd der Transport beim Senden und erneuten Senden sein soll. Haben beide Endpunkte die Unterstützung für FORWARD TSN beim Aufbau der Association ausgehandelt, kann der Sender eine Nachricht aufgeben und dem Empfänger mitteilen, den kumulativen Transmission Sequence Number (TSN)-Punkt vorzuverlegen. Bei geordneten Nachrichten helfen zusätzliche Stream-Sequenznummern, Daten freizugeben, die hinter der Lücke warten.

Die Regel, die den Abbruch auslöst, ist nicht das Signal, das den Empfänger weiterbringt. Er muss nicht wissen, ob der Sender wegen einer Frist, einer begrenzten Zahl von Wiederholungen oder einer anderen Dienstregel aufgegeben hat. Er muss nur wissen, welche TSNs nicht mehr als fehlend gelten und welche geordneten Nachrichten deshalb weitergereicht werden können. FORWARD TSN übermittelt die Transportfolge der Entscheidung, nicht ihre Anwendungsmotivation.

Der Blick auf die frühere Lebensdauerregel zeigt die Änderung. In RFC 2960 konnte ein lifetime-Parameter verhindern, dass eine noch nie gesendete, inzwischen veraltete Nachricht erstmals übertragen wurde. War die erste Übertragung vor Ablauf erfolgt, musste die Nachricht dagegen wie gewöhnliche zuverlässige Daten weiterbehandelt und erneut gesendet werden. Der timed-reliability-Dienst aus RFC 3758 hob diese Einschränkung auf: Auch eine bereits erstmals gesendete Nachricht durfte nach Ablauf ihrer Lebensdauer aufgegeben werden.

Aber „darf aufgegeben werden“ bedeutete nicht „wird im Ablaufmoment aufgegeben“. Der Sender muss die Lebensdauer vor der TSN-Vergabe prüfen und, sobald eine TSN vergeben ist, vor dem Senden oder erneuten Senden. Zugleich erklärt RFC 3758, dass kein eigener Timer für jede einzelne Nachricht nötig ist. Die Implementierung kann bei ohnehin anfallenden Arbeitsschritten prüfen — etwa bei TSN-Vergabe, Übertragung oder Ablauf eines Wiederholungstimers — oder bei einer anderen passenden Gelegenheit. Eine sofortige Prüfung genau beim Ablauf wird nicht verlangt.

Ein API-Feld namens lifetime ist deshalb noch keine Zusage für eine harte Echtzeitfrist. Es kann festlegen, dass eine Nachricht nach der Prüfung nicht mehr gesendet werden soll; es legt nicht zwangsläufig fest, wann der Stack diese Prüfung ausführt. Zeitkritische Anwendungen müssen den möglichen Abstand zwischen Fristablauf und Auswertung als Teil des Dienstvertrags behandeln.

Auch die Phase der Nachricht verändert die Folgen. Läuft die Lebensdauer vor der TSN-Vergabe ab, kann der Sender die Nachricht ohne eine zu überwindende Sequenzlücke verwerfen. Nach der Vergabe gehört die TSN zum gemeinsamen Sequenzraum der Association; der Sender markiert die Daten als aufgegeben und muss gegebenenfalls FORWARD TSN senden. Bei einer fragmentierten Nachricht müssen alle weiteren Fragmente zugleich aufgegeben werden, sobald eines davon aufgegeben wird. TSN- und Stream-Sequenzraum sind unterschiedliche Ordnungsebenen. Das Signal verbindet sie, ohne den fehlenden Inhalt als empfangen auszugeben.

FORWARD TSN ist keine Empfangsquittung. Es besagt, dass der Sender bestimmte TSNs nicht weiter verfolgt und der Empfänger sie überspringen soll. Es belegt weder den Empfang der aufgegebenen Nutzdaten noch die Annahme einer folgenden Nachricht durch die Anwendung noch die Einhaltung einer Ende-zu-Ende-Frist. Die Staukontrolle bleibt bestehen: Aufgegebene Daten dürfen das Congestion Window nicht erhöhen, und erforderliche Anpassungen an Wiederholungsereignisse entfallen nicht.

Die Fähigkeit muss außerdem für die Association ausgehandelt sein. Meldet der Peer keine Unterstützung für FORWARD TSN, kann diese Association die Erweiterung nicht verwenden. Eine Anwendung, die davon abhängt, muss das Ergebnis kennen und entscheiden, ob sie den Aufbau abbricht oder einen anderen Dienst nutzt. Lokale Implementierung und gemeinsam ausgehandelte Fähigkeit sind nicht dasselbe.

RFC 7496 ergänzte später Richtlinien für begrenzte Wiederholungen und Prioritäten. So können mehrere Dienstregeln denselben Mechanismus für den Sequenzfortschritt verwenden. Die obere Schicht entscheidet, wann ein weiterer Versuch seinen Wert verloren hat; der Transport definiert, wie die Gegenseite nach dem Abbruch weiterkommt.

Quellen