10. Il controllo della congestione: evitare il collasso della rete

In questa lezione analizzeremo le strategie fondamentali per gestire il traffico dati ed evitare il fenomeno del collasso della rete. Esploreremo i meccanismi di controllo della congestione essenziali per mantenere l'efficienza nelle comunicazioni.

Comprendere come i protocolli gestiscono il sovraccarico è cruciale per ogni studente di sistemi e reti. Approfondiremo le architetture moderne progettate per garantire stabilità e prestazioni ottimali in ogni scenario.

  • shape
  • shape


Il controllo della congestione: evitare il collasso della rete

Nella lezione precedente abbiamo visto come il Controllo del Flusso (Flow Control) garantisca che un server super-veloce non saturi la memoria RAM di un client troppo lento. Tuttavia, quel meccanismo end-to-end agisce come se il server e il client fossero collegati da un cavo diretto e indistruttibile. La realtà è molto diversa: nel mezzo ci sono decine di router, e ognuno di essi deve smistare il traffico di migliaia di altre connessioni simultanee.

Cosa accade se milioni di computer cercano di inviare i loro file alla massima velocità possibile attraverso una rete centrale che ha una larghezza di banda limitata? Le code di memoria (Buffer) dei router intermedi si riempiono fino a scoppiare, provocando la distruzione massiva dei pacchetti IP. Questo fenomeno non è solo un rallentamento, ma una minaccia architetturale nota come Congestive Collapse (Collasso da Congestione), che negli anni '80 paralizzò letteralmente Internet. Per evitare che la rete si autodistrugga, il protocollo TCP implementa i rigorosi e complessi algoritmi di Controllo della Congestione (Congestion Control).

La minaccia fantasma e l'assenza di feedback di Rete

Il vero dramma della congestione è che genera un circolo vizioso. Se un router si riempie e inizia a scartare pacchetti, i mittenti non riceveranno gli ACK. I timer di RTO (Retransmission Timeout) dei mittenti scadranno. A questo punto, per le regole dell'affidabilità ARQ, ogni mittente inietterà nella rete una "Ritrasmissione" degli stessi pacchetti. Invece di alleviare il carico sul router in difficoltà, i mittenti lo bombardano con pacchetti duplicati, portando il throughput (traffico utile) della rete esattamente a zero  .

La sfida ingegneristica per risolvere questo disastro risiede nel protocollo IP sottostante: i router IP sono "stupidi" e stateless. Se un router sta per esplodere a causa del traffico, non invia alcun messaggio di allerta ai mittenti. Il protocollo TCP dei computer mittenti deve "indovinare" alla cieca lo stato di congestione dei router invisibili, basandosi esclusivamente sui tempi di arrivo degli ACK o sulla loro assenza.

Il paradigma TCP: La Congestion Window (cwnd)

Per tastare il polso della rete, il sistema operativo del mittente istituisce una seconda variabile matematica segreta (non visibile nell'header dei pacchetti), chiamata Congestion Window (Finestra di Congestione o cwnd).

La formula assoluta del Limite di Trasmissione: Da questo momento, il mittente ha due freni da dover rispettare. Il freno del ricevitore (rwnd) e il freno della rete (cwnd). Il TCP stabilisce matematicamente che la vera Finestra Scorrevole (la quantità massima di dati unacknowledged in volo) deve essere uguale al minimo tra questi due valori: Window = MIN(rwnd, cwnd)  . Anche se il client dice di avere Gigabyte di RAM libera, se la rete è intasata e la cwnd è piccola, il mittente obbedirà alla rete per non causare il collasso.

Slow Start: sondare il terreno alla cieca

Quando una connessione inizia, il mittente non ha idea di quale sia la capacità della rete. Usa quindi l'algoritmo Slow Start (Partenza Lenta). Il mittente setta la sua cwnd al valore ultra-conservativo di 1 MSS (Maximum Segment Size, tipicamente 1460 byte). Può inviare quindi un solo pacchetto.

Se il pacchetto arriva e riceve l'ACK, significa che la rete sta reggendo. L'algoritmo stabilisce che per ogni singolo ACK ricevuto, la cwnd aumenta di 1 MSS. Dal momento che l'invio di un pacchetto genera un ACK, al turno successivo invierà 2 pacchetti, che genereranno 2 ACK, portando la finestra a 4, poi a 8, a 16, a 32. Paradossalmente, il termine "Slow Start" è ingannevole: la crescita della finestra è una violenta progressione esponenziale. Si parte lentamente, ma si raddoppia la velocità a ogni Round Trip Time (RTT), cercando di saturare il canale nel minor tempo possibile.

Congestion Avoidance: il rallentamento (AIMD)

Naturalmente, la crescita esponenziale causerebbe la catastrofe in pochi secondi. Il TCP mantiene un'altra variabile interna, la ssthresh (Slow Start Threshold - Soglia). Quando l'esplosione esponenziale della cwnd oltrepassa questa soglia, il sistema operativo capisce che si sta avvicinando ai limiti fisici dei router intermedi.

Il TCP abbandona la fase esponenziale ed entra nella fase Congestion Avoidance (Evitamento della Congestione). Ora, invece di raddoppiare, la finestra cresce in modo ultra-cauto: aumenta di un solo MSS complessivo per ogni intera finestra di pacchetti confermati. È una crescita puramente Lineare. Questa filosofia tecnica è nota come AIMD (Additive Increase, Multiplicative Decrease): esplora la rete dolcemente aggiungendo poca banda per volta (Incremento Additivo), ma fatti prendere dal panico e taglia le prestazioni di netto se sospetti che un pacchetto sia andato perso (Decremento Moltiplicativo).

Rilevamento della perdita: Triple Duplicate ACK vs Timeout

Il protocollo TCP discrimina l'intensità della congestione interpretando il modo in cui i pacchetti vanno persi. Esistono due eventi scatenanti e due reazioni totalmente diverse:

[tooltip]Timeout (Disastro Totale): Se il timer RTO (Retransmission Timeout) scade senza che arrivino più ACK, il TCP sentenzia che la rete centrale è completamente collassata e i router non riescono più a muovere i pacchetti. La reazione è brutale: la soglia `ssthresh` viene dimezzata, ma la `cwnd` viene fatta precipitare istantaneamente al valore base di 1 MSS. La connessione torna a 1500 byte al secondo per lasciar respirare i router, ricominciando lo Slow Start dall'inizio.[/tooltip] I Tre ACK Duplicati (Fast Retransmit e Fast Recovery): Se un mittente invia i pacchetti 10, 11, 12, 13 e il pacchetto 11 viene distrutto da un router per un micro-picco di traffico, il pacchetto 12 e il 13 arriveranno ugualmente. Il ricevitore invierà l'ACK per il pacchetto 10, e quando riceve il 12 invia un "ACK 10" duplicato (per avvisare che gli manca l'11). Quando arriva il 13, invia un terzo "ACK 10" duplicato. Se il mittente riceve 3 ACK Duplicati, l'algoritmo capisce che la rete NON è morta (infatti gli ACK stanno continuando a circolare fluenti), ha solo subìto uno sbalzo. Si attiva il Fast Retransmit: il mittente ritrasmette immediatamente il pacchetto 11 senza aspettare lo scadere del lunghissimo Timeout. Contestualmente, entra nel Fast Recovery: la `cwnd` non viene distrutta e azzerata a 1, ma viene solo tagliata a metà, permettendo al download di non crollare ai livelli del 1990 ma di riprendersi linearmente.

Sintesi applicativa e autoverifica

Se il Flow Control usa l'rwnd per evitare il buffer overflow a destinazione, il Congestion Control calcola una finestra "invisibile" (cwnd) per prevenire il collasso delle infrastrutture Internet. Attraverso cicli continui di Slow Start esponenziale, Congestion Avoidance lineare e tagli drastici dettati dai Timeout o dai Tripli ACK, il protocollo TCP traccia sul grafico una curva a "Dente di Sega" (Sawtooth), cercando perennemente l'equilibrio matematico perfetto sulla banda disponibile.

Mettiti alla prova su un paradosso tipico dell'esame Cisco: un potentissimo server sta streammando dati via TCP. L'applicazione client sul ricevitore sta leggendo i dati lentissimamente, per cui il suo Receive Buffer si è riempito quasi del tutto. L'ultimo ACK inviato dal client comunica una striminzita finestra `rwnd` di appena 4.380 byte (circa 3 MSS). Contemporaneamente, la rete in mezzo è vuota, la fibra è scarica, e la `cwnd` calcolata dal server è schizzata a 500.000 byte. Il server sta per trasmettere il nuovo blocco: sapendo la formula di coesistenza matematica delle due finestre, quanti byte esatti sarà autorizzato a inviare il server come suo limite assoluto in quel preciso istante?

Paragrafi letti

 

    
0%
       Salva

Esercizi su "10. Il controllo della congestione: evitare il collasso della rete"

0%

Statistics