Zusammenfassung

  • DCCPs CCID 2 übermittelt Empfangsinformationen zuverlässig, ohne verlorene Anwendungsdaten erneut zu senden. Die Zuverlässigkeit des Berichts ist ein anderes Versprechen als die Zuverlässigkeit der Datenübertragung.
  • Ack Vectors komprimieren Empfangsverläufe. Gelegentliche Bestätigungen dieser Berichte erlauben dem Empfänger, alte Zustände freizugeben, besonders wenn nur noch eine Anwendung Daten sendet.
  • Geht die zweite Bestätigung verloren, bleibt der alte Zustand länger bestehen. Eine dritte Bestätigung ist deshalb nicht nötig. CCID 3 hat andere Zustandsanforderungen und benötigt nicht dieselbe Regel.

Zwei Bits Zustand, sechs Bits Wiederholung

Der Ack Vector in RFC 4340 ist zunächst eine sparsame Darstellung. Zwei Bits eines Bytes kennzeichnen den Empfangszustand, sechs weitere die Länge einer Folge mit demselben Zustand. Der Längenwert null steht für ein Paket, 63 für 64 Pakete. Eine gleichförmige Empfangsgeschichte muss also nicht Paket für Paket ausgeschrieben werden.

Die Zustände unterscheiden empfangen, mit ECN-Staumarkierung empfangen, einen reservierten Wert und noch nicht empfangen. Der Vektor beginnt bei der Bestätigungsnummer des Pakets und beschreibt von dort aus ältere Pakete. Seine Größe hängt damit auch davon ab, wie stark sich die Zustände abwechseln, nicht nur davon, wie viele Pakete er erfasst.

Diese Darstellung löst jedoch nicht die Frage, wann die Geschichte gelöscht werden darf. Der Empfänger kann sie bereits mehrfach gesendet haben, ohne zu wissen, ob auch nur ein vollständiger Bericht beim Sender angekommen ist. Kompression reduziert die Kosten einer Nachricht; sie beendet nicht deren Zweck.

Genau diesen zweiten Schritt organisiert DCCP mit Bestätigungen von Bestätigungen. Die Gegenseite teilt mit, welchen Bericht sie erhalten hat. Erst dadurch entsteht eine belastbare Grenze für die Freigabe alter Empfangsinformationen.

Ein Transport ohne Pflicht zur Wiederholung alter Inhalte

Warum braucht ein unzuverlässiger Datentransport eine solche Sorgfalt? Die im März 2006 veröffentlichten DCCP-Dokumente trennten zwei Aufgaben, die häufig gemeinsam auftreten. RFC 4336 beschreibt Anwendungen, die Staukontrolle brauchen, aber selbst entscheiden wollen, ob verlorener Inhalt noch nützlich ist.

Ein verspäteter Sprachabschnitt hat seinen Abspielzeitpunkt möglicherweise verpasst. Eine alte Position in einem Spiel kann weniger wert sein als die aktuelle. Die Anwendung möchte die nächste zulässige Sendemöglichkeit mit den passenden Daten füllen, statt zwangsläufig eine vergangene Lücke zu reparieren.

DCCP sendet verlorene Anwendungsdaten nicht erneut. Eine Anwendung kann eigene selektive Zuverlässigkeit ergänzen; das Transportprotokoll übernimmt aber nicht die vollständige Wiederherstellung eines Datenstroms. Die Entscheidung über den zeitlichen Wert des Inhalts bleibt damit von der Entscheidung über die erlaubte Sendemenge getrennt.

Die Staukontrolle benötigt trotzdem Informationen über Verluste und Markierungen. CCID 2 überträgt diese Empfangsinformationen zuverlässig. Dass ein alter Inhalt nicht nachgeliefert werden muss, bedeutet nicht, dass die Beobachtung seines Verlusts verschwinden darf. Die Erinnerung dient der nächsten Sendeentscheidung, nicht der rückwirkenden Vervollständigung des Inhalts.

Auch Berichte haben eine eigene Sequenznummer

DCCP zählt Pakete statt Bytes. Jede Sendung erhöht die Sequenznummer, auch eine reine Bestätigung ohne Anwendungsdaten. So wird der Rückkanal selbst beobachtbar: Auch dort können Nummern fehlen.

Die Bestätigungsnummer nennt die größte empfangene Sequenznummer. Sie behauptet nicht, dass sämtliche kleineren Nummern angekommen seien. Die Lücken dazwischen werden durch Optionen wie Ack Vector beschrieben. Wer den Wert wie die kumulative Byte-Grenze von TCP liest, würde dem Feld eine Zusage zuschreiben, die DCCP gerade nicht macht.

Umgekehrt ist die Vektorhistorie über ihr Bestätigungsfenster kumulativ angelegt. Es wäre also ebenso falsch, DCCP pauschal jede kumulative Information abzusprechen. Feld und Bericht erfüllen unterschiedliche Funktionen.

Eine Sequenzlücke kann ausschließlich Steuerpakete betreffen. Die bei aktivierter Funktion verwendete Option NDP Count meldet die unmittelbar vorangehende Folge von Nicht-Datenpaketen und hilft, diesen Fall zu erkennen. Sie ist weder ein Zähler verlorener Nutzdatenbytes noch eine vollständige Aufschlüsselung jeder gemischten Verlustfolge.

Auch der Zustand empfangen bleibt auf eine bestimmte Ebene beschränkt. DCCP hat die Optionen verarbeitet und kann das Paket bestätigen; die Anwendung muss die Daten noch nicht übernommen haben. Ein Verwerfen im Anwendungspuffer wird nicht als Verlust auf dem Netzwerkweg ausgegeben. Dafür gibt es die zusätzliche Information Data Dropped.

Eine Richtung verstummt, eine Pflicht bleibt

Bei beidseitigem Datenverkehr gehen die notwendigen Bestätigungen gewöhnlich im normalen Austausch mit. B meldet, was von A angekommen ist; A bestätigt seinerseits Pakete von B. Der Verwaltungsaufwand ist mit ohnehin benötigten Übertragungen verbunden.

Stellt B das Senden von Anwendungsdaten ein, empfängt aber weiterhin A, ändert sich diese Lage. B sendet nun reine Bestätigungen. Würde A nur DCCP-Data weiterschicken, bekäme B keine ausdrückliche Nachricht darüber, welcher seiner Berichte angekommen ist.

RFC 4341 verpflichtet den aktiven Sender deshalb, die Bestätigungen des Empfängers gelegentlich zu bestätigen. Als Möglichkeit kann ein DCCP-DataAck an die Stelle eines DCCP-Data treten. Empfohlen ist mindestens eine solche Bestätigung pro Staufenster, nicht ein eigener zusätzlicher Rückruf auf jedes einzelne Ack.

Wenn beide Anwendungen schweigen, kann der Sender beliebig lange warten. Das ist kein Widerspruch: Ohne neue Daten ist die Dringlichkeit anders als bei einem weiter aktiven Sender. Eine pauschale Regel für eine vermeintlich inaktive Gesamtverbindung würde diese unterschiedlichen Situationen verdecken.

Was die zweite Bestätigung tatsächlich beendet

Der Empfänger unterscheidet Informationen, deren Kenntnis die Gegenseite bereits bestätigt hat, von gemeldeten, aber noch nicht sicher angekommenen Informationen und von noch nicht gemeldeten. Die beiden letztgenannten Gruppen bilden das Bestätigungsfenster. Neue Empfangsvorgänge vergrößern es, bestätigte Berichte lassen den älteren Rand nachrücken.

Ohne diesen Ausgang könnte der Empfänger bei CCID 2 immer wieder Informationen bis zurück zum Verbindungsbeginn senden. Die zweite Bestätigung beendet einen Teil dieser Berichtspflicht. Sie bestätigt nicht die Reparatur eines verlorenen Datagramms.

Eine weitere Bestätigungsebene ist nicht notwendig, weil die zweite Nachricht selbst nicht zuverlässig zugestellt werden muss. Geht sie verloren, hält der Empfänger die alte Information länger vor und meldet sie erneut. Die Unsicherheit führt zu zusätzlicher Aufbewahrung, nicht zu einer verfrühten Freigabe.

Verlust bleibt damit kostspielig. Doch die Kosten liegen in längerem Zustand und wiederholtem Rückverkehr, nicht in einer endlos wachsenden Kette neuer Zustellversprechen. Die Abstufung der Folgen beendet die Rekursion.

Ein Timer erklärt den Ruhezustand nicht allein

Für CCID 2 ist die Wartezeit zur Erkennung von Ruhe das Maximum aus 0,2 Sekunden und zwei Umlaufzeiten. Hinzukommen muss eine zweite Bedingung: Der Sender hat die Ack Vectors bestätigt, die sämtliche empfangenen Daten abdecken.

Ein Zeitablauf ohne neue Daten genügt also nicht. Bei unbekannter Umlaufzeit gilt ein Standard-RTT von 0,2 Sekunden; der Term von zwei RTTs ergibt dann 0,4 Sekunden. Die Regel als festen 200-Millisekunden-Schalter darzustellen wäre falsch.

Die beiden Übertragungsrichtungen können zudem unterschiedliche CCIDs verwenden. Der CCID einer Richtung bestimmt deren Ruheerkennung. Der CCID der anderen bestimmt, wie anschließend die Bestätigungen bestätigt werden. Eine Verbindung hat damit nicht nur einen undifferenzierten Speicherzustand.

Eine neue Erkenntnis darf nicht mit dem alten Bericht verschwinden

Anhang A.3 von RFC 4340 zeigt ein nichtnormatives Implementierungsbeispiel. Ein Datensatz verknüpft die Sequenznummer eines abgesandten Berichts mit der von ihm beschriebenen Empfangshistorie. Seine Bestätigung kann die Freigabe dieser alten Informationen auslösen.

Schwierig wird es, wenn ein zuvor fehlendes Paket verspätet eintrifft. Bestätigt der Sender danach den älteren Bericht, kennt er zunächst weiterhin nur die frühere Abwesenheit. Die inzwischen festgestellte Ankunft muss noch übertragen werden.

Das Beispiel begrenzt deshalb gegebenenfalls den Freigaberand, damit eine neue Erkenntnis nicht zusammen mit einem bestätigten alten Bericht gelöscht wird. Es schreibt nicht jedem System denselben Ringpuffer vor. Es zeigt, dass der Löschpunkt vom nachgewiesenen Wissensstand des Gegenübers abhängt.

Auch umgeordnete Berichte müssen richtig zusammengeführt werden. Eine später eintreffende alte Meldung über ein fehlendes Paket darf eine bereits bekannte Ankunft nicht beliebig überschreiben. Ankunftszeit eines Berichts und Aktualität seines Inhalts sind nicht dasselbe.

Die andere Art, den Zustand zu begrenzen

RFC 4342 spezifiziert CCID 3 mit TFRC. Der Preis eines gleichmäßigeren Durchsatzes ist eine langsamere Reaktion auf Änderungen verfügbarer Kapazität. Nach der DCCP-Grundspezifikation ist der Bestätigungszustand dieses Profils im Allgemeinen begrenzt; derselbe Mechanismus zur Bestätigung der Bestätigungen ist daher nicht erforderlich. Zustandslos ist CCID 3 deshalb nicht.

Seine verifizierten Errata korrigieren unter anderem das Messintervall der Empfangsrate auf das letzte RTT, statt die ganze Zeit seit der vorherigen Rückmeldung zu verwenden. Wird eine zweite Receive-Rate-Option im vorgesehenen Fall ohne Daten im betrachteten Intervall ignoriert, darf auch der Timer für ausbleibende Rückmeldung nicht zurückgesetzt werden. Ein eingetroffenes Steuerpaket verlängert nicht automatisch die Gültigkeit jeder Annahme.

Die Errata zu RFC 4340 berichtigen ein Beispiel, das Ack Ratio null fälschlich als ungültig behandelte, sowie redaktionelle Angaben im Anhang. RFC 8311 entfernte 2018 die ECN-Nonce-Diskussion aus drei DCCP-Profilen. Die Texte von 2006 dürfen nicht ohne diese Entwicklung als aktuelle Betriebsanweisung dienen.

RFC 6773 ergänzte 2012 UDP-Kapselung für bestimmte Einschränkungen durch zwischengeschaltete Geräte. Sie ändert nicht die fehlende zuverlässige Zustellung von Anwendungsdaten. Das IANA-Register wiederum belegt die Zuweisung von Kennungen, keine heutige Verbreitung.

Die Quellen tragen deshalb keinen universellen Leistungsgewinn und keine Aussage über einen konkreten aktuellen Produktbestand. Sie tragen eine präzisere historische Erkenntnis: Ein kleiner Bericht kann eine große offene Verantwortung enthalten. Erst eine passende Bestätigung, nicht die Kompression, beendet sie.