Frage an TCP Experten / Typische Anzahl an Retransmissions

Hallo zusammen,

soweit ich das aus den Posts rauslesen kann sind ja hier auch einige Informatiker oder Personen mit Erfahrung im Netzwerkberich unterwegs.

Ich hätte da eine Frage an euch. Und zwar: Wie hoch ist die typische Anzahl an Retransmissions einer TCP Verbindung?
Ich weiß, die Frage ist ziemlich ungenau, daher zu dem Hintergrund. Ich schreibe gerade an meiner Diplomarbeit und werte dabei den TCP Traffic über eine UMTS Verbindung aus. Dabei sollen unter anderem die Retransmissions vom Server zum Client als Metrik dienen. Da eine TCP Verbindung ja in der Slow Start- und danach in der Congestion Avoidance Phase stetig das Congestion Window erhöht und sich daher an die Grenze der Bandbreite herantastet, habe ich ein regelmäßiges Vorkommen von Retransmissions, neben den Retransmissions durch Verluste über Funkstrecke und ähnliches, erwartet.
Jedoch messe ich nur sehr selten Retransmissions. Bei einem Download einer 10MB Datei nur 1-3 oder so.
Ist das normal? Hat jemand Erfahrung mit TCP Tracefiles und kann bestätigen, das dies auch in anderem Umfeld (z.B. Lan, Wireless Lan) so ist? Hat jemand eine Idee warum keine Retransmissions auftreten obwohl der Throughput nicht weiter steigt, sondern sich z.B. bei 1400 Kb/s einpendelt?

Hoffe ich habe mich klar genug ausgedrückt. Falls noch Fragen sind, einfach stellen. Hoffe es gibt ein paar Anregungen von euch.

Besten Dank

Tom

Hi.

Die mittlere RTT der Pakete liegt bei ca. 250 - 300ms (ist eine UMTS Verbindung).

Meinst du mit TCP-Window das Advertised Window, welches bei in jedem TCP-Paket angibt, wie groß der Pufferplatz beim Empfänger noch ist?
Das hatte ich auch schon in Verdacht. Wenn ich mir jedoch die ACKs des Empfängers im Tracefile des Servers anschaue, stehen im entsprechenden TCP-Header Feld ziemlich große Zahlen. Der Wert startet bei etwa 65500 und verringert sich meist pro ACK ein wenig bis auf etwa 50000 oder so und wird dann durch ein TCP Window Update wieder auf den Startwert angehoben.

Interpretiere ich die Zahlen falsch? So wie ich das sehe ist genug Pufferplatz beim Empfänger vorhanden, so dass das Advertised Window nicht der limitierende Faktor ist.
Bleibt also nur das Congestion Window, was nach meinem Wissen doch nur durch einen Fast Retransmit oder einen Timeout gesenkt wird, aber ansonsten stetig steigt.
Oder hab ich hier einen Denkfehler? (Scheint ja so, sonst würden die Ergebnisse ja meinen Gedanken entsprechen )

Gruß

Tom

P.S.: Wenn jemand ein anderes Forum weiß, wo ich noch nachfragen könnte, kann mir das gerne schreiben. Ich weiß ja, dass das hier nicht wirklich das richtige Forum für eine solche Frage ist

Hi.

Ich meinte natürlich 1400 Kbit/s, sorry, war missverständlich. Aber 1400KByte/s über UMTS wär schon der Hammer, das würde ich sofort kaufen

Aber mal zurück zum Thema. Mir ist schon klar, das der Sender ein sogenanntes Sliding Window hat, welches anzeigt, wieviele Daten er noch senden darf. Dieses berechnet sich aus dem Advertised Window, welches vom Empfänger pro TCP Paket zum Sender gesendet wird und dem COngestion Window, welches beim Sender durch den Slow Start und die Congestion Avoidance Phase kontinuierlich erhöht wird. Das Sliding Window ist dann das Minimum der beiden anderen Windows.
Und wenn in den ACK-Paketen des Empfägers das Advertised Window nicht auf Null oder zumindest einen geringen Wert fällt, müsste doch eigentlich das Sliding Window (durch das Congestion Window bedingt) weiter steigen bis es zu einem Timeout oder eienm Fast Retransmit kommt. Ganz nach dem schönen Sägezahn Muster, das für eine TCP Verbing immer als typischer Verlauf aufgezeigt wird.

Oder kann es sein, dass das Advertised Window mit den 65500 Byte(?) doch der begrenzente Faktor ist? Müsste ich mal durchrechnen. Aber das mache ich erst morgen. Fahre jetzt erstmal von der Arbeit nach Hause

Danke für die Antworten. Ich freue mich über weitere. Werde auch nachher zuhause nochmal reinschauen.

Gruß

Tom