|
Il
Controllo della Congestione
-
-
Esistono almeno due notevoli problemi col TCP, relativi alla congestione
della rete ed al meccanismo di "timeout and retransmission".
La congestione è una condizione di ritardo critico causata da un
sovraccaricamento dei datagrammi in uno o più switching points (es.
router). Quando avviene una congestione, il ritardo aumenta ed i routers
iniziano ad accodare datagrammi, finchè non sono in grado di
instradarli.
Nel peggiore dei casi, il numero dei datagrammi che arrivano ad un
router congestionato cresce (esponenzialmente nel tempo) fino a che esso
non raggiunge la sua massima capacità e comincia a perdere datagrammi.
Dal punto di vista degli hosts, la congestione è semplicemente un
aumento di ritardo.
Inoltre, poichè la maggiorparte dei protocolli usa un meccanismo di
timeout and retransmission, essi rispondono al ritardo ritrasmettendo
datagrammi, aggravando così la congestione.
Un aumento di traffico produce un aumento di ritardo, che provoca a sua
volta un aumento del traffico, e così via, finchè la rete non può essere
più usata: tale condizione è detta Congestion Collapse (Collasso dovuto
alla congestione).
Non esiste un meccanismo esplicito per risolvere il controllo della
congestione, anche se un'attenta implementazione del TCP/IP può permette
di individuare ed affrontare meglio la situazione.
Esistono due modi per affrontare il problema della congestione di rete:
recuperare la funzionalità una volta che la congestione ha avuto luogo (Recovery)
oppure evitarla (Avoidance).
Per evitare il collasso della rete, il TCP può utilizzare la tecnica del
Multiplicative Decrease Congestion Avoidance. Il TCP/IP mantiene un
secondo limite, oltre dimensione della finestra del ricevente, detto
congestion window limit; in oogni istante il TCP assume come dimensione
della finestra di trasmissione, la minima tra le due.
In condizioni normali, le due finestre sono uguali, ma in condizioni di
congestione, la congestion window riduce il traffico che il TCP immette
in rete, dimezzando la propria dimensione ogni volta che si perde un
segmento (fino ad un minimo di uno). Il rate di trasmissione è ridotto
in modo esponenziale ed il valore del timeout viene raddoppiato per ogni
perdita.
Se, una volta superata la congestione, si dovesse invertire la tecnica
del Multiplicative Decrase, raddoppiando la congestion window, si
avrebbe un sistema instabile che oscillerebbe ampiamente tra assenza di
traffico e congestione.
Per ripristinare le condizioni di normale funzionamento, una volta che è
avvenuto il collasso, il TCP può invece adottare una tecnica di Slow
Start Recovery. Non appena inizia il traffico su una nuova connessione o
aumenta dopo un periodo di congestione, la congestion window ha la
dimensione di un singolo segmento ed ogni volta che arriva un ACK, viene
incrementata di uno.
In questo modo, dopo aver trasmesso il primo segmento ed aver ricevuto
il suo ACK, la finestra di congestione viene raddoppiata; una volta
inviati i due segmenti, per ogni ACK ricevuto la congestion window sarà
incrementata di una unità, così il TCP potrà spedire quattro segmenti, e
così via, fino a raggiungere il limite imposto dalla finestra del
ricevente.
Per evitare che la dimensione della finestra si incrementi troppo
velocemente e causi congestione addizionale, il TCP impone una ulteriore
restrizione. Una volta che la finestra di congestione raggiunge la metà
del suo valore originale, il TPC entra in una fase di congestion
avoidance e rallenta il rate di incremento; in questo caso la dimensione
della finestra sarà incrementata di una sola unità dopo che tutti i
segmenti della finestra hanno ricevuto ACK.
La combinazione delle due tecniche di Recovery ed Avoidance migliora
drasticamente le prestazioni del TCP senza bisogno dell'aggiunta di
ulteriori strumenti per il controllo della congestione. |
