Ausweichmanöver

Netzwerk-Staus mit dem Datagramm Congestion Control Protocol vermeiden

Praxis & Tipps | Praxis

TCP und UDP begründen als dominierende Internet-Protokolle eine solide, laufend an neue Herausforderungen angepasste Infrastruktur.

Das Internet ist bekanntlich kein für die Ewigkeit entworfener, allen Widrigkeiten trotzender Rechnerverbund. Über Jahrzehnte weiterentwickelte Algorithmen bilden ein stabiles Fundament aus eng miteinander verzahnten Teilen. Dem Internet-Protokoll (IP) liegt das Prinzip des verbindungslosen Paketdienstes zu Grunde, also der Datentransport mittels Routing. IP transportiert aber auch Steuerungsinformationen. Die Transportschicht baut auf Funktionen der Netzwerkschicht auf und erweitert sie um Eigenschaften wie verbindungsorientierte, byteorientierte, vollduplexfähige Datenübertragung (TCP) oder dessen verbindungsloses Pendant (UDP).

Das Verhältnis von verbindungsorientiertem zu verbindungslosem Verkehr hat eine grundlegende Bedeutung. TCP enthält eine Stauerkennung (Congestion Control), UDP nicht. Würde ein Großteil der Daten über UDP transportiert, würde das Internet zusammenbrechen (RFC 3714, wie alle RFCs unter anderem zu finden via www.ietf.org/rfc.html): Router wären hoffnungslos überlastet, könnten dies aber nicht anzeigen, weil UDP es nicht vorsieht.

Ein Stau entsteht bei der Überlastung eines Routers; sein Paketpuffer ist erschöpft. Um Abhilfe zu schaffen, verwirft er im einfachsten Fall Pakete aus der Warteschlange (Drop Tail). Die beteiligten TCP-Instanzen reagieren im weiteren Verlauf mit einem Algorithmus, der die Senderate minimiert. Das gleichzeitige Verwerfen von Paketen aus der Queue führt zu einem neuen Problem, der "globalen Synchronisation": Alle betroffenen TCP-Instanzen gehen zum selben Zeitpunkt in "Fast Recovery" mit der Folge, dass auf eine Zeitspanne mit wenig Auslastung eine gebündelte Datenübertragung (Burst) folgt. Random Early Detection (RED) erweitert diesen Ansatz. Es versucht drohende Staus früh zu erkennen und verwirft einzelne Pakete vorzeitig unter Zuhilfenahme eines Schwellenwertes.

Auf diesem Algorithmus baut die Explicit Congestion Notification (ECN) auf ­ mit einem kleinen, aber entscheidenden Unterschied. Anstatt Pakete zu verwerfen, markiert sie Pakete bei Staugefahr und fordert den Sender damit auf, die Übertragung zu bremsen. Der Vorteil liegt auf der Hand: Das erneute Übertragen verworfener Pakete entfällt. ECN nutzt zur Markierung zwei Bit im DiffServFeld (RFC 2474, früher ToSByte) und zwei Bit im TCP-Header. Verständlicherweise muss der komplette Kommunikationspfad ECN-kompatibel sein. Es darf keinen Router oder Endknoten aus dem Takt bringen, wenn "mysteriöse" Bits gesetzt sind (http://urchin.earth.li/ecn/ listet Soft- und Hardware auf, die damit Probleme haben). Linux ab Kernelversion 2.4 und Cisco IOS ab Version 12.2 unterstützen ECN.

Ein anderer Ansatz zum Anzeigen von Stausituationen besteht im Versenden von Nachrichten namens "ICMP Source Quench" (RFC 792). Die Endsysteme erfahren auf diese Weise, dass Kapazitätsgrenzen erreicht sind. Bei einer akuten Überlastung zusätzlichen Verkehr zu erzeugen, erscheint jedoch wenig sinnvoll. Für die Motivation eines Streaming-Protokolls wie DCCP (Datagram Congestion Control Protocol), das als Transportprotokoll auf der gleichen Ebene wie TCP oder UDP arbeitet, ist ein Blick auf deren Eigenschaften hilfreich.

Anzeige
Anzeige