The Cable Guy - Oktober 2006
Explicit Congestion Notification (ECN) für TCP/IP
Von The Cable Guy
Alle auf Deutsch verfügbaren Cable Guy-Kolumnen finden Sie unter http://www.microsoft.com/germany/technet/community/columns/cableguy/cgarch.mspx.
Router, auf denen zu viel Netzwerkverkehr auftritt und deren Paketpuffer voll sind, fangen an, Pakete zu verwerfen. Dies wirkt sich auf das Netzwerk durch eine reduzierte Bandbreite, den Verlust von zeitkritischen Datenübertragungen und möglichen Verbindungsausfällen aus. Explicit Congestion Notification (ECN) für TCP/IP gibt Routern die Möglichkeit, TCP-Peers (Transmission Control Protocol) darüber zu informieren, dass ihr Puffer aufgrund von zu viel Netzwerkverkehr voll ist. Die Peers können dann ihre Übertragungen einschränken und mögliche Paketverluste vermeiden. Dieser Artikel beschreibt, wie ECN arbeitet und wie es unter Microsoft® Windows Vista™ RC1 unterstützt wird.
Hinweis:Dieser Artikel setzt fundiertes Wissen über IP, TCP und IP-Routing voraus.
Auf dieser Seite
 | Einführung |
| Explicit Congestion Notification |
| ECN-Unterstützung unter Windows |
| Zusätzliche Informationen |
Einführung
Moderne TCP-Implementierungen behandeln das Netzwerk zwischen TCP-Peers als "Black-Box". Pakete mit TCP-Segmenten gehen in die Black-Box und kommen heraus. Manchmal geht ein Paket rein und wird verworfen. Da Bitfehler bei den heutigen digitalen und optischen Medien relativ rar sind, gingen die Designer von TCP davon aus, dass der wahrscheinlichste Grund für verworfene Pakete in einer Überlastung des Routers zu sehen ist - der Puffer für eingehende Pakete auf dem Router ist bis an seine Kapazitätsgrenze ausgelastet, und daher verwirft der Router neue eingehende Pakete stillschweigend.
TCP erkennt, dass Pakete verworfen wurden und überträgt sie dann neu. Durch die notwendige Neuverarbeitung auf dem TCP-Peer, die Neuübertragung und den verringerten Netzwerkdurchsatz ist dies jedoch ein sehr kostenintensiver Prozess.
Wenn ein sendender TCP-Peer verworfene Pakete entdeckt, überträgt er das Segment neu. Er reduziert dann das Sendefenster (die Anzahl der Segmente, die er senden kann, bevor er auf ein Acknowledgement wartet) und führt den "Slow start and congestion avoidance algorithm" (RFC 2001) aus. Dies führt dazu, dass die Übertragungsrate des Senders sofort sinkt und der Router die Möglichkeit hat seinen Puffer zu leeren. Der Sender vergrößert das Sendefenster dann schrittweise wieder auf den alten Wert.
Auch wenn verworfene Pakete nicht besonders schön sind, haben sie jedoch keine negativen Auswirkungen auf die Datenübertragung an sich. Es ist einfach nur mehr Zeit erforderlich, um die verworfenen Segmente neu zu übertragen. Außerdem wird die Übertragungsrate, wie gerade besprochen, erst nach und nach wieder auf den ursprünglichen Wert gesetzt. Der "Slow start and congestion avoidance algorithm" funktioniert bei nicht-zeitkritischem Netzwerkverkehr wunderbar. Bei Netzwerkverkehr, der zeitkritisch ist oder bei dem der Verlust von Paketen zu Problemen führt, ist dies jedoch nicht der Fall.
Ein weiteres Problem ist der Effekt, den die Überlastung des Routers auf verschiedene Datenübertragungen hat. Wenn ein Router eingehende Pakete verwirft, unterscheidet er normalerweise nicht zwischen den einzelnen Übertragungen. Wenn es bei mehreren TCP-Übertragungen Paketverluste gibt, müssen alle entsprechenden Sender die Fenstergröße verringern und Pakete neu übertragen. Abhängig davon, wie schnell der Router seinen Puffer leert, kann es sein, dass die Sender alle ihre Fenstergröße verringern und diese zeitgleich nur langsam wieder erhöhen. Dies führt möglicherweise dazu, dass die Auslastung des Routers nun viel zu gering ist.
Das ganze Verfahren stellt den nicht sonderlich effektiven Versuch dar, die zu hohe Routerauslastung vom sendenden Host aus zu beheben - und zwar mit keinem anderen Indikator, als verlorenen Paketen. Daher haben die Entwickler von TCP/IP neue Standards für Hosts und Router entworfen. Sie werden in RFC 2309 (Active queue management (AQM) on IP routers" beschrieben und ermöglichen es Routern, den Status ihrer Forwarding-Queues zu überwachen. Außerdem bieten Sie einen Mechanismus, mit dem der Router den sendenden Host darüber informieren kann, dass er ausgelastet ist. So hat der Host die Möglichkeit, die Übertragungsrate zu verringern, bevor der Router Pakete verwirft. Dieser Mechanismus wurde in RFC 3168 unter der Überschrift "Explicit Congestion Notification (ECN)" beschrieben.
Mit diesem Verfahren müssen die Hosts bei einer Überlastung zwar noch immer die Übertragungsrate verringern, es kommt jedoch nicht mehr zu Paketverlusten.
Explicit Congestion Notification
ECN für TCP/IP nutzt nicht verwendete Bits in den IP- und TCP-Headern.
| • | Auf der Internetschicht (IP) muss ein sendender Host anzeigen können, dass er mit ECN arbeiten kann. Ein Router muss anzeigen können, dass er ausgelastet ist. |
| • | Auf der Transportschicht (TCP) müssen die TCP-Peers sich gegenseitig anzeigen können, dass sie ECN-fähig sind. Ein empfangender Peer muss den sendenden darüber informieren können, dass ein Router ausgelastet ist. Der sendende Peer muss den empfangenden Peer darüber informieren können, dass er dies wahrgenommen hat und seine Übertragungsrate verringert. |
ECN-Unterstützung von IP
Das 8-Bit-Feld Type of Service (TOS) im IP-Header wurde ursprünglich in RFC 791 definiert. In RFC 2474 wurde es jedoch umdefiniert und enthält nun einen 6-Bit-DSCP (Differentiated Services Code Point) und zwei nicht verwendete Bits. Der DSCP-Wert dient dazu, die Priorität des Paketes festzulegen. Die zwei nicht verwendeten Bits werden hingegen von ECN genutzt. In der folgenden Abbildung sehen Sie, wie sich das TOS-Feld aufteilt.
Die beiden ungenutzten Bits des in RFC 2474 definierten TOS-Feldes werden in RFC 3168 als ECN-Feld definiert. Sie haben die folgenden Werte:
| • | 00 - Der sendende Host unterstützt ein ECN. |
| • | 01 oder 10 - Der sendende Host unterstützt ECN. |
| • | 11 - Ein Router ist ausgelastet. |
Wurde das ECN-Feld von einem Router auf 11 gesetzt (Router ausgelastet), so wird es von nachfolgenden Routern nicht mehr modifiziert.
ECN-Unterstützung von TCP
Wenn das ECN-Feld eines IP-Paketes durch einen Router auf 11 gesetzt wird, weiss der Empfänger, dass der Pfad überlastet ist - der Sender weiss dies jedoch nicht. Mit dem TCP-Header zeigt ECN auch dem Sender an, dass das Netzwerk ausgelastet ist.
Für ECN werden zwei, bis jetzt als "Reserviert" definierte, Bits im TCP-Header verwendet. Diese zwei neuen Flags sind folgendermaßen definiert:
| • | ECE: Das ECE-Flag (ECN-Echo) wird verwendet, um anzuzeigen, dass ein TCP-Peer ECN-fähig ist. Dies geschieht während des 3-Wege-Handshakes von TCP. Außerdem zeigt es an, dass ein TCP-Segment empfangen wurde, bei dem der IP-Header auf 11 gesetzt ist. Weitere Informationen zum 3-Wege-Handshake finden Sie in RFC 793. |
| • | CWR: Das CWR-Flag (Congestion Window Reduced) wird vom sendenden Host gesetzt. Es zeigt an, dass diese ein TCP-Segment mit gesetztem ECE-Flag empfangen hat. |
In der folgenden Abbildung sehen Sie, wo sich die beiden Flags relativ zu den anderen Flag im TCP-Header befinden. Weitere Informationen zu den anderen Flags im Header finden Sie in RFC 793.
Wenn zwei ECN-fähige TCP-Peers eine TCP-Verbindung aufbauen, tauschen Sie SYN-Segmente (Synchronize), SYN-ACK-Segmente (SYN-Acknowledgement) und ACK-Segmente aus. Bei ECN-fähigen Peers wird im SYN-Segment das ECE- und CWR-Flag gesetzt. Im SYN-ACK-Segment ist das ECE-Flag gesetzt und das CWR-Flag nicht.
Ein ECN-fähiger Host sendet TCP-Segmente für eine TCP-Verbindung mit aktiviertem ECN mit dem Wert 01 oder 10 im IP-Header. Ein ECN-fähiger Router, der ausgelastet ist, setzt das Feld im IP-Header auf 11. Wenn ein empfangender TCP-Peer ein ACK für Daten eines TCP-Segments sendet, bei dem das ECN-Feld auf 11 gesetzt wurde setzt er das ECE-Flag im TCP-Header (und zwar auch in allen weiteren ACKS).
Wenn der sendende Host ein ACK mit ECE-Flag empfängt, verhält er sich, als wäre das Paket verworfen worden. Er reduziert seine Fenstergröße und führt den "Slow start and congestion avoidance algorithm" aus. Beim nächsten Segment setzt der Sender das CWR-Flag. Beim Empfang dieses neuen Segments mit CWR-Flag, hört der Empfänger auf, dass ECE-Flag in den ACKs zu setzen.
ECN-Beispiel
In der folgenden Abbildung sehen Sie ein Beispiel für eine TCP-Verbindung zwischen zwei ECN-fähigen TCP-Peers.
TCP-Peer A sendet Daten an TCP-Peer B. TCP-Peer A sendet die Segmente 1 bis 5. Segment 2 wird von einem ECN-fähigen Router weitergeleitet, der ausgelastet ist. Dieser setzt das ECN-Feld im IP-Header auf 11. Wenn Peer B das Segment empfängt, sendet er ACKs mit ECE-Flag. Wenn Peer A das erste ACK mit ECE-Flag empfängt, verringert er seine Übertragungsrate und sendet das nächste Segment (6) mit CWR-Flag. Nach dem Empfang von Segment 6, hört Peer B auf, dass ECE-Flag zu setzen.
Weitere Informationen zur Arbeitsweise von ECN finden Sie in RFC 3168.
ECN-Unterstützung unter Windows
Window Vista RC1 unterstützt ECN zwar, es ist jedoch standardmäßig deaktiviert. Um es zu aktivieren, verwenden Sie den Befehl netsh interface tcp set global ecncapability=enabled. Da ECN Bits im IP- und TCP-Header nutzt, kann es sein, dass Netzwerkgeräte Pakete mit ECN-Feldern, die nicht auf Null gesetzt sind, verwerfen. Um sicherzustellen, dass ECN-TCP/IP-Netzwerkverkehr nicht irgendwo in Ihrem Netzwerk verworfen wird, sollten Sie das Netzwerk gründlich überwachen und gegebenenfalls entsprechende Aktualisierungen vornehmen.
Zusätzliche Informationen
Weitere Informationen zu den TCP/IP-Erweiterungen unter Windows Vista finden Sie unter den folgenden Ressourcen:
| • | |
| • | Next Generation TCP/IP-Stack unter Windows Vista und Windows Server Longhorn |
| • |