TCP flow control, congestion avoidance

TCP flow control, congestion avoidance
Einleitende Worte:
Zunächst einmal, warum lohnt es sich TCP auf zwei Vorträge aufzuteilen?
Im ersten Vortrag haben wir gehört, wie TCP aufgebaut ist und wie es arbeitet.
Ganz am Ende wurde erwähnt, das TCP (fast) perfekt ist. Die Betonung liegt
hierbei auf fast. In der Vergangenheit wurde einfach nur drauf los gesendet. Bald
hat man erkannt das dies zu Problemen, sprich Datenstau führt.
Warum dies der Fall ist und wie man das verhindern kann, erörtern wir in folgendem Vortrag.
Ergänzung: Sliding Window
Letzte Woche haben wir unteranderem das Sliding Window -Prinzip kennengelernt.
Hierzu ist nur noch folgende, kleine Ergänzung zu machen. Das Sliding Window
besteht nicht nur aus 2 Pointern, sondern aus 3. Dieser dritte Pointer dient als
Grenze zwischen den schon gesendeten und den noch zu sendenden Octets und
befindet sich somit im Window selber. Auf Grund dessen weiß der Sender immer,
was schon gesendet ist und was nicht. Dies dient insofern zur Sicherheit, dass das
Window nicht weiter als die schon gesendeten Pakete rücken kann und somit Daten vergessen werden.
Als Beispiel hierfür:
• Die Octets 1-2 wurden versand und bestätigt
• Octet 3-6 wurden gesendet, aber noch nicht bestätigt
1
• 7-9 wurden noch nicht gesendet, werden es aber ohne Verzögerung
• 10-... können erst gesendet werden, wenn das Fenster verschoben wurde
Da TCP die Octest ohne Verzögerung versendet, rückt diese Trennung schnell nach
rechts.
Ergänzung: Delayed Acknowledgements
ACKs werden nicht immer dirket versendet. Das TCP wartet bis zu 200ms mit
dem Versenden damit ggf. noch weitere Daten (ACKs) in einem ACK versendet
werden können. Die 200ms werden durch einen Timer angegeben, der beim Kernelstart gestartet wird. Somit beträgt die Wartezeit nicht immer genau 200ms.
Dies bewirkt, dass nicht so viel Traffic entsteht und somit potentielle Congestions
vermieden werden.
In einem Beispiel sind Zeiten von 42.0 bis 195.8ms aufgekommen. Dies kommt daher, dass der Timer nicht gestartet wird, wenn ein Paket angekommen ist, sondern
relativ zum KernelBoot läuft. Die Gesammzeit ist größer als 200ms, da sie von
einem fixen Punkt ausgeht.
Ergänzung zum letzten Vortrag:
Der Timer wird beim Kernelstart gestartet, nicht beim Empfang des ersten Paketes. Somit beträgt die Zeitverzögerung zwischen 1-200ms.
Das selbe Phänomen haben wir beim Timeout gesehen. Hier beträgt der Timer
500ms relativ zum KernelBoot.
Nagle Algorithm
(RFC 896 [Nagle 1984])
Der Nagle-Algorithm ist eine andere Lösung um unnötige Acknowledgements/Congestion
zu vermeiden.
Der Nagle-Algorithm verhindert das Verschicken 41byte großer Pakete. Dies ist bei
langsameren Netzwerken sehr nützlich und entlastet den Daten-Traffic.
Das Prinzip ist sehr einfach. Wird ein Paket vom Sender verschickt wartet dieser solange mit dem verschicken des nächsten Paket, bis das ausstehende ASK
empfangen wurde. Somit werden ggf. angefallene 41byte-Pakete gesammelt und
zusammen verschickt.
2
Ab und an macht es aber Sinn den Nagle-Algorithm auszuschalten, z.B. bei XWindow. Hier will man, dass die Mausbewegung in “Echtzeit”übertragen wird, sowie beim Drücken einer Funktionstaste. (Erinnerung: eine Funktionstaste braucht
3bytes) Durch den Nagel-Algorithm wird dieses verzögert.
Slow Start
Slow Start bestimmt die Größe des Sliding Window, also wie viele Pakete aufeinmal gesendet werden. Hierzu benutzt es das Congestion Window (cwnd ), welches
die Anzahl der gleichzeitig zu schickenden Pakete angibt. Das cwnd wird mit 1
initialisiert und bei Ankunft des ACKs für das erste Paket auf 2 erhöht. Kommen
auch die beiden ACKs für die nächsten Pakete an, so wird es auf 4 erhöht. Das
cwnd erfährt also durch Slow Start eine exponentielle Steigerung.
Congestion Avoidance
Da der Anteil am Paketverlust durch Beschädigung weniger als 1% beträgt ist es
wichtig, die größte aller Verlustursachen, den Paketverlust durch Datenstau und
einfaches Wegwerfen des Paketes auf Serverseite zu verhindern. Da Slow Start das
cwnd exponentiell steigert kann es sehr schnell zu hohen Senderaten kommen, mit
denen viele Server im Internet einfach nicht fertig werden, deshalb greift hier Congestion Avoidance ein.
Congestion Avoidance und Slow Start sind zwei verschiedene Algorithmen, jedoch
wird Congestion Avoidance eingesetzt, um Slow Start “im Zaum“ zu halten, deshalb werden beide immer zusammen implementiert.
Congestion Avoidance benötigt zusätzlich zum cwnd auch noch das Slow Start
threshold size (ssthresh). Wenn eine Verstopfung auftritt, so wird im ssthresh die
Hälfte der Paketanzahl gespeichert, die zu einer Verstopfung geführt hat und das
cwnd wird auf 1 gesetzt. Dann übernimmt Slow Start wieder die Steigerung der
Paketanzahl, wie oben beschrieben. Wenn nun das cwnd die gleiche Menge an Paketen angibt die das ssthresh gespeichert hat, übernimmt Congestion Avoidance.
Nun wird die Anzahl der Pakete bei jeder Rount-Trip Time nur um 1/cwnd, aber
mindestens um 1 Paket gesteigert.
Round Trip Time
Die RTT ist eine für TCP fundamentale Funktion denn sie hilft dabei sinnvolle
Entscheidungen zu treffen, ob ein Paket nun wirklich verloren gegangen ist oder ob
nur das ACK noch unterwegs ist und verhindert somit unnötige Retransmissions.
Die RTT wird beim ersten Paket gemessen und dann durch einen Formel in eine
geschätze Zeit umgewandelt, die eventuelle Routenänderungen einkalkuliert. Die
3
RTT wird mit jedem ankommenden ACK neu berechnet, wobei die neu berechnete
Zeit zu 10% mit in die Berechnung für die gesamt Zeit eingeht. Die RTT wird nach
folgender Formel berechnet:
R ← αR + (1 − α) · M
R gibt die geschätzte gesamt RTT an, M ist die gemessene RTT und α ist ein
Glättungsfaktor, der empfohlenerweise immer bei 0,9 liegen sollte.
Silly Window Syndrom
Das SWS ist ein Fehler, der sehr schön demonstriert was alles passieren kann,
wenn man einfach drauf los sendet, so wie es früher geschehen ist als diese ganzen
hilfreichen Algorithmen noch nicht implementiert waren. Das SWS zeichnet sich
dadurch aus, dass der Empfänger immer wieder ein Datenfenster von einem Byte
angibt und so der Sender auch immer wieder 41 Byte Pakte verschickt. Auf der
anderen Seite kann aber auch der Sender von sich aus 41 Byte Pakete versenden,
wenn er einfach jeden Tastendruck sofort an den Empfänger übermittelt. Rechnet
man nun noch die ganzen ACKs hinzu, so kommt man auf eine beträchtliche Anzahl von Paketen, die hin und her geschickt werden und so ganze Netze überlasten
können.
Quellen:
• W. Richard Stevens: TCP/IP Illustrated, Vol.1
• Douglas E. Comer: Internetworking with TCP/IP, Vol.1
4