[ Main | Local ]

Karn Algorithmus - Exponentieller Backoff

rto_limit ist die Anzahl der Schritte zwischen den eingestellten Werten für rto_high und rto_low. In dem Augenblick, wo man rto_limit Retransmissions gesendet hat, ist der Timeout gleich rto_high - er steigt nicht mehr.

Der Parameter rto_length gibt die gesamte Anzahl an Retransmissions an, die gesendet werden. Daher muß rto_limit immer kleiner als rto_length sein. Sonst setzt der Algorithmus rto_limit auf den größten möglichen Wert, also rto_length. Hier der Zusammenhang im Bild:

.   low                                 high
.   |  |  |  |  |  |  |  |  |  |  |  |  |  |
.    ==
.   Limit
   <-----------------------Length------------------------->

Die Granularität ist unter AIX 500 Millisekunden. Die Rundlaufzeit kann also nur bis auf eine halbe Sekunde genau bestimmt werden. Der erste Retransmission Timeout wird aus den ersten, guten Messungen der Rundlaufzeit berechnet. Dazu wird die "smoothed round trip time" und deren Varianz ermittelt. Der so ermittelte Wert ist immer höher als die Granularität, und erst nach langem, gleichmäßigem Datentransfer kann sich der schrittweise verfeinerte Timer der Granularität annähern. In dieser Zeit darf es natürlich zu keiner Retransmission eines Paketes kommen. Der Default-Wert für rto_low ist unter AIX 1 Sekunde, sodaß man eh nicht unter die Granularität kommt.

Der Retransmission Timer läuft nur, wenn effektiv Daten zwischen den Endpunkten hin und her gehen (nur so kann man Rundlaufzeiten ermitteln). Das heißt, das in FIN_WAIT_1 der Timer benutzt wird, in FIN_WAIT_2 aber nicht - hier kommen die Daten ja nur noch von der anderen Seite, eine Rundlaufzeit ist nicht mehr zu ermitteln. Die persistenten Timer laufen in FIN_WAIT_1 auch, wenn die Gegenstelle kleine Windows anzeigt.

Telnet bricht erst dann ab, wenn die darunterliegende TCP-Verbindung abbricht. Das hängt von der Anzahl der gewählten Retransmissions ab, was der no-Parameter "rto_length" wiederspiegelt.

Ein Beispiel

Meine TCP Verbindung hat lange gut funktioniert, und ich habe eine RTT von Z Sekunden. Jetzt sind alle rto-Werte auf Standardwerte gesetzt, also gilt:
rto_low = 1
rto_high = 64
rto_limit = 7
rto_length = 13

Bei einer berechneten RTT von Z wird also bei einem fehlenden ACK auf ein gesendetes Paket nach Z Sekunden dieses Segment neu gesendet. Jetzt ist der Bereich zwischen Low und High in 7 Teile geteilt, was einen Intervall von 9 ergibt. Kommt auf das neu gesendete Paket auch kein ACK innerhalb von 9*Z Sekunden, so wird nochmal gesendet. Jetzt wird 18*Z Sekunden gewartet. Das wiederholt sich solange, bis man den High-Wert erreicht. Der Timeout ist jetzt 64*Z Sekunden und 8 Pakete sind ohne Antowrt gesendet worden. Jetzt werden mit diesem Timeout (64*Z Sek.) bis maximal 13 Pakete verschickt. Dann wird die Verbindung als verloren betrachtet und der Socket geschloßen.

Kommt eine Antwort, also ein ACK, so wird mit dem hohen Timeout solange weitergesendet, bis wieder ein sicherer Messwert für die RTT zur Verfügung steht - es muß in jedem Fall verhindert werden, daß RTT über wiedergesendete Pakete berechnet werden. Nach der ersten guten Messung wird diese RTT genommen und die Zähler zurückgesetzt.

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]