TCP-Offload – Fluch oder Segen?

Kommentieren Drucken

Vor einiger Zeit war ich einem wahrhaft mysteriösen Fehler auf der Spur: Massive Performance-Probleme bei einer Server-Server-Verbindung, die über ein Weitverkehrsnetz geführt wurde. Wie so oft war Bandbreite satt vorhanden und die Auslastung verschwindend gering – also kein Netzwerkproblem. Die Protokollanalyse zeigte, dass es immer wieder Paketverluste gab. Auch das ist weder ungewöhnlich noch Besorgnis erregend. Allerdings traten immer wieder Timeouts auf. Die Kommunikationspartner ließen sich Zeit beim Wiederholen der verlorenen Pakete, und das war der Grund für die schlechte Performance.

Erstaunlich dabei war der folgende Sachverhalt: Beide Kommunikationspartner unterstützten ein Verfahren, das eine besonders schnelle Reaktion auf Paketverluste ermöglicht. Dabei erfährt der Sender nicht nur, welches das letzte empfangene Paket vor dem ersten Paketverlust war sondern auch, welche Pakete nach diesem Paketverlust wieder erfolgreich empfangen wurden. Mit dieser Information kann sich der Sender die tatsächlich zu wiederholenden Pakete frühzeitig „zurechtlegen“. Interessant im vorliegenden Fall war, dass beide Kommunikationspartner das geschilderte Verfahren (Selective Acknowledgement, SACK gemäß RFC 2018 et. al.) zwar beim Verbindungsaufbau aushandelten, letztlich aber keinen Gebrauch davon machten. Die entsprechende Option fehlte schlicht in den Datenpaketen!

Ein wenig ratlos habe ich mich an die Betreiber der Server gewandt. Die haben daraufhin allerlei herumprobiert (neue Netzwerkkartentreiber, TCP-Einstellungen im Betriebssystem, usf.) bis sie auf die Option „Large-Send-Offload“ in den Einstellungen der Netzwerkkarte stießen. Die haben sie deaktiviert und damit das Problem gelöst.

Daraufhin habe ich mich ein wenig mit dem Thema „TCP Offload“ beschäftigt. In der Tat finden sich im Internet zahlreiche Berichte darüber, dass dieses Verfahren zu Problemen aller Art geführt habe. Hersteller von Virtualisierungs-Plattformen raten davon ab, es einzusetzen. Auf der anderen Seite liest man, dass 10-Gigabit-Ethernet auf Servern eine erhebliche Prozessorbelastung verursache und TCP Offload hier eine Erleichterung bringe. Was stimmt nun?

TCP Offloading verlagert Teile der TCP/IP-Verarbeitung von der CPU auf die Netzwerkkarte. Dort werden im einfachsten Fall Prüfsummen berechnet, Daten segmentiert und wieder zusammengesetzt. Das Betriebssystem reicht einen großen Datenblock bei der Netzwerkkarte ein, den diese in Ethernet-typische Häppchen (Segmente) zerlegt und aussendet. Das entlastet die CPU ein wenig.

Größere Entlastung kann erzielt werden, wenn die Netzwerkarte komplexere Aufgaben der TCP-Arbeit erledigt, sich also beispielsweise um das gesamte Verbindungsmanagement kümmert. Dazu ist jedoch eine enge Kopplung zwischen dem TCP des Betriebssystems und der Netzwerkkarte erforderlich. Microsoft hat einen solchen Ansatz mit seinem TCP Chimney Offload vorgestellt, das es bereits seit Windows Server 2003 gibt. Voraussetzung für den Einsatz von TCP Chimney ist eine kompatible Netzwerkkarte.

Die enge Kopplung zwischen Betriebssystem und Netzwerkkarte ist jedoch ein „Pferdefuß“ des TCP Offload. Seit seiner Erfindung vor über 30 Jahren wird TCP immer weiter optimiert und fortentwickelt. Gerade in jüngster Zeit sind zahlreiche neue Entwicklungen zu beobachten, die sich z.B. mit dem Problem hoher Bandbreiten und Latenzen befassen (mein „Standpunkt“ vom November 2011). Die Betriebssysteme implementieren derlei Verfahren zeitnah, aber die Hersteller von Netzwerkkarten ziehen nicht nach. Offensichtlich ist also die Performance doch kein so großes Problem wie ursprünglich angenommen. Oder drücken wir es anders aus: Die Leistung der Server-Prozessoren wächst so schnell, dass sich die kostspielige Entwicklung intelligenter Netzwerkarten erübrigt.

Kehren wir zurück zum Anfang. Microsoft fordert bestimmte Features für TCP-Chimney-kompatible Netzwerkkarten. Die Unterstützung von SACK (s.o.) ist dabei nur optional. Das Compound TCP (CTCP), welches Windows seit Server 2008 eingeführt hat, braucht gar nicht unterstützt zu werden. Somit werden mit TCP Offload wesentliche Elemente der TCP-Leistungssteigerung, nämlich SACK und CTCP, praktisch deaktiviert. Vergessen Sie also TCP Offload und deaktivieren Sie es, wo Sie nur können.

zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.