Archief - TCP Congestion Control & Flow Control

MaSSaSLaYeR zei:

Hello!

Ik zit wat in de knoop met de 2.

Flow control gebruikt aan de sender & receiver een buffer de "Receive Window".
Elke keer dat een segment binnekomt gaat de size van de buffer omlaag aan de sender en de receiver. Maar hoe speelt de Receive Window in het packet hier een rol in? Dus ik zie de big picture eventjes niet.

Congestion control heeft alleen een buffer aan de sender side de "congestion window". Maar ik kan mij daar niks bij voorstellen?
Wat ik wel weet is dat TCP Tahoe slow start gebruikt om het senden van packets te verdubbelen tot er een loss event of timeout is en vervolgens gaat hij daarna nog maar 1/10 van de packets sturen en dan terug proberen de verdubbelen tot er een nieuw loss event of timeout is.

Timeout: Als er geen ACK's meer toekomen?
Loss event: duplicate ACK's?

TCP Reno gebruikt dan weer Fast Recovery waarbij de Congestion Window elke x verhoogt met 1 tot er een timeout of loss event is en dan vermindert hij het senden met de helft?


Dank u aan de persoon die mij dit een beetje duidelijk kan uitleggen, liefst in eigen woorden

Greetz!

Klik om te vergroten...

NeverwinterX zei:

Flow control:
De receive window geeft aan hoeveel bytes data de sender mag sturen naar de receiver zonder dat de receiver een ack terug stuurt naar de sender. Dus pas na die bytes zal de receiver een ach terugsturen. De receiver moet dus een buffer voorzien (plaats in het geheugen) om die data in op te slaan, zodat die de data kan controleren of die ok is, voordat die een ack terug stuurt. De sender moet eveneens dezelfde hoeveelheid bufferen, want stel dat de receiver geen ack terugstuurt, dan moet de sender opnieuw die data kunnen terugsturen en moet dat dus bijhouden. Maar het is misschien ietwat verwarrend om die buffer aan de sender side ook "receive window" te noemen. Met de receive window wordt dus zowel de buffer die hiervoor voorzien wordt aangeduid, als de het getal dat aan geeft hoe groot dat window is, dat zorgt mss voor wat verwarring bij jou. In het TCP packet staat telkens ook dit getal zodat sender en receiver weten hoeveel ze mogen sturen en ze moeten bufferen.

Congestion control:
Flow control en congestion control beschermen tegen twee verschillende dingen: flow control om te voorkomen dat de sender meer data stuurt dan de receiver kan opslaan in geheugen en afhandelen, congestion control beschermt tegen het overflowen van een zwaarbelast netwerk. Stel dat door een zwaarbelast netwerk pakketjes kunnen verloren gaan: de sender side gaat dat pas later merken doordat er geen ack binnenkomt en moet dus een buffer bijhouden van wat hij doorstuurt, zodat hij dat opnieuw kan doorsturen als er iets fout loopt. Het congestion window is dus gelijkaardig aan het receive window aan de sender side: je zult misschien opmerken dat er dan toch dingen dubbel opgeslagen worden. Een slimme implementatie zal dan ook niet letterlijk 2 buffers voorzien, maar eentje met als grootte het maximum van het receive window en congestion window

Timeout: de sender krijgt geen ack voor een pakket binnen het interval
Loss event: definitie varieert nog al eens, vaak "timeout of 3 dup acks"

TCP Tahoe en Reno gebruiken allebei slow start, maar bij een loss event gedragen ze zich licht verschillend:
- Tahoe zet het congestion window terug op 1 en begint terug te slow starten
- Reno halveert het congestion window en probeert het zo eerst eens; als er terug een probleem optreedt zet hij het congestion window ook terug op 1 voor terug een slow start

Succes met uw examen netwerken

Klik om te vergroten...

MaSSaSLaYeR zei:

Al zeer bedankt voor de duidelijk uitleg!

Nog een paar opmerkingen:

Flow control:
Zeer goede uitleg nu versta ik Silly Window Syndrome ineens ook duidelijker.

Congestion Control:
In het boek zeggen ze soms dat een loss event 2 dup ACK's is en soms 3 dup ACK's maar ze zeggen niet wat het verschil is?

TCP Tahoe en Reno
Aah zo! Nu zie ik waarvoor dien treshold dient!

Nogmaals dank u voor de goede uitleg!!
You are awesome!

Klik om te vergroten...

NeverwinterX zei:

Van die ack's heb ik toch wat moeten opzoeken.
Je weet dat de receiver als er pakketjes niet in volgorde binnenkomen dat die opnieuw een ack stuurt voor het laatste pakketje dat hij tegoei in volgorde kreeg. Als de sender dan een dubbele ack krijgt voor eenzelfde pakket, weet die dat er iets mis ging met de volgorde en stuurt hij de pakketjes na die waarvoor de ack was, opnieuw. Nu als er opnieuw en opnieuw acks binnenkomen voor hetzelfde pakket, dan rijst het vermoeden dat er niet zomaar eenmalig iets fout gaat met de volgorde, maar dat er netwerkproblemen zijn. Met moet dus ergens (relatief arbitrair) een lat leggen en zeggen: vanaf zoveel duplicate acks gaan we ervan uit dat er netwerkproblemen zijn.

Uit de TCP specificatie:
" Since TCP does not know whether a duplicate ACK is caused by a lost segment or just a reordering of segments, it waits for a small number of duplicate ACKs to be received. It is assumed that if there is just a reordering of the segments, there will be only one or two duplicate ACKs before the reordered segment is processed, which will then generate a new ACK. If three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost. "

Klik om te vergroten...