DCCP könnte helfen

Netzwerk-Staus mit dem Datagramm Congestion Control Protocol vermeiden

Praxis & Tipps | Praxis

Seite 3: DCCP könnte helfen

Mit dem RFC 4340 liegt mittlerweile eine Protokollspezifikation vor, die sich den Beschränkungen von UDP annimmt: DCCP, ein neues Protokoll, das eine Stauvermeidung bei der Übertragung von unzuverlässigen Datagrammen ermöglicht. Vereinfacht ausgedrückt handelt es sich um UDP, angereichert mit Staukontrollalgorithmen und anderen technischen Ingredienzen aus der Protokollküche.

DCCP soll Designfehler anderer Protokolle von vornherein vermeiden. Den Autoren zufolge darf es keine anwendungsspezifischen Informationen enthalten, sondern vielmehr nur absolut notwendige Funktionen. Aus den genannten Gründen ergeben sich die im Folgenden beschriebenen Eigenschaften:

  • Zuverlässiger Verbindungsauf- und -abbau, unterteilt in den Austausch von Request-, Response- und Acknowledge-Paketen. Anders als bei TCP kann schon das erste Paket (DCCP Request) Nutzdaten transportieren.
  • Zuverlässige Aushandlung der Paketoptionen. Das betrifft auch die Auswahl des geeigneten Staukontrollmechanismus mit Unterstützung von ECN: derzeit CCID 2 oder 3 (Congestion Control IDentifier, siehe unten).
  • Unzuverlässiger Paketstrom mit Bestätigungen (DCCPAck). Anders als TCP ist DCCP kein Bytestrom-Protokoll. Die Anwendung ist zuständig für das Segmentieren.
  • Unterstützung von Path Maximum Transmission Unit Discovery (RFC 1191). Dieser Mechanismus ermittelt die maximale Paketgröße für eine Wegstrecke.
  • Vermeidung von Verbindungszuständen, die nicht vollständig aufgebaut sind. DCCP nutzt einen kryptographischen Algorithmus mit dem Namen Init-Cookie. TCP kennt diese Erweiterung unter einem anderen Namen: SYN-Cookie.
  • Ein Bestätigungsmechanismus, der Paketverlust- und ECN-Informationen übertragen kann, und zwar mit einer Zuverlässigkeit, wie sie der Staukontollmechnismus verlangt.
  • Optionale Mechanismen, die Aufschluss über die empfangenen Daten liefern und beschädigte oder verworfene Pakete erkennen.

DCCP verwendet CCIDs für die Auswahl des Staukontrollverfahrens. Derzeit sind zwei davon definiert: CCID 2 (Standard bei neu aufgebauten Verbindungen) und CCID 3. Soll ein alternativer Mechanismus zum Einsatz kommen, muss dies der Kommunikationspartner erfahren. Die AlgorithmusAuswahl erfolgt pro Richtung, die Teilverbindung A-B kann ein anderes Verfahren nutzen als die Teilverbindung B-A.

Im IETF-Draft als "TCP-like Congestion Control" bezeichnet, bildet DCCP die Eigenschaften von TCP in Bezug auf Stauvermeidung nach. Außerdem unterstützt es Ack-Vektoren, einen an selektive Acknowledgements (SACK) angelehnten Algorithmus. Im Unterschied zu "Vanilla TCP" findet die Staukontrolle auch bei Bestätigungspaketen Anwendung. Das ergibt einen hohen Durchsatz, allerdings mit massivem Einbruch in Stausituationen, da sich wie bei TCP das Staukontrollfenster halbiert. CCID 2 eignet sich daher für Anwendungen, die ein Maximum an Durchsatz fordern und im Gegenzug von sich aus einen mehr oder minder konstanten Datenfluss gewährleisten, etwa durch kurzzeitiges Zwischenspeichern. Der Entwurf von CCID 2 liefert ausführliche und umfassende Informationen und sei ausdrücklich empfohlen.

CCID 3 (TFRC, TCP-friendly Rate Control) ergänzt CCID 2 und eignet sich für einen gleichmäßigen Datenstrom. Auf Änderungen der Übertragungskapazität reagiert es daher langsamer. Anwendungen, die diesem Verhalten den Vorzug geben, sollten auf CCID 3 zurückgreifen, müssen den Protokolleigenschaften aber durch eine möglichst gleichmäßige Übertragung und identische Paketgrößen entgegenkommen. Dazu gehören aktuelle VoIP-Protokolle auf Anwendungsebene.

Im DCCP-Entwurf finden zahlreiche Sicherheitsaspekte Berücksichtigung. Dazu gehören PMTU Discovery, die zufällige Wahl der Sequenznummer und ein "Init Cookie", das die Speicherung von Zuständen vermeidet, bis der Dreiwege-Verbindungsaufbau abgeschlossen ist.

Außerdem verfügt DCCP über eine Vielzahl von Eigenschaften, die sich besonders gut für den Einsatz hinter Firewalls eignen – anders als verbindungslose Protokolle wie UDP. Es baut eine virtuelle Verbindung auf, eine ideale Grundlage für das Connection Tracking. Falls eine Anwendung nicht mit dem gewohnten Port kommuniziert, liefert das Servicefeld im Header zu-dem die Information, um welches Anwendungsprotokoll es sich dabei handelt. In Zeiten, da Administratoren ihr Teilnetz in ein enges Korsett schnüren, ein nicht zu vernachlässigender Aspekt.

Anzeige