# Silly window syndrome

La silly window syndrome (sindrome da finestra sciocca, abbreviata con SWS) è un problema legato alla cattiva implementazione del controllo di flusso a livello TCP. Un processo di scrittura molto lento da parte del mittente nel buffer di trasmissione (o di lettura da parte del ricevente) porta infatti all'invio di segmenti di dati molto piccoli, aumentando così il rapporto tra header e dati con un conseguente uso inefficiente del canale.

## Sindrome causata dal mittente

Nel caso in cui il processo di scrittura dei dati nel buffer TCP del mittente sia molto lento, il protocollo spedirà una serie di pacchetti contenenti una quantità di dati molto bassa, con un uso inefficiente del canale (è infatti molto meglio spedire un solo pacchetto con $n$ byte di dati, per il quale bisogna pagare il peso di un solo header, che spedire $n$ pacchetti contenenti solo un byte di dati, per ognuno dei quali bisogna pagare il peso di un header, un rapporto di $1/n$ contro $n/n=1$).
La soluzione a questo problema consiste nel trattenere i dati nel buffer allo scopo di spedirli in un unico segmento. Tuttavia un'attesa troppo lunga potrebbe causare dei ritardi troppo grandi nella trasmissione.
Un'ottima soluzione a questo problema è fornita dall'algoritmo di Nagle, secondo il quale i dati devono essere accumulati nel buffer per poi venire spediti in un unico blocco alla ricezione dell'ACK dell'ultimo pacchetto trasmesso o quando si raggiunge la massima dimensione fissata per un segmento (MSS). Questo semplicissimo algoritmo riesce a risolvere il problema tenendo anche conto della velocità di trasmissione dei pacchetti: se questa è più lenta della scrittura dei messaggi (il mittente riesce ad accumulare una notevole quantità di dati nel buffer prima dell'arrivo del riscontro) vengono creati pacchetti con il massimo rapporto dati/header, sfruttando al meglio le risorse del canale. Se invece la rete è più veloce, i pacchetti risulteranno più piccoli, assicureranno una certa continuità nella trasmissione e verrà garantito comunque un utilizzo più efficiente delle risorse del canale che nel caso in cui l'algoritmo non venga utilizzato.

## Sindrome causata dal ricevente

Nel caso sia invece il ricevente a leggere lentamente i pacchetti ricevuti, il buffer in ingresso tenderà a riempirsi, costringendo a richiedere al mittente di interrompere la trasmissione. Non appena un frame viene letto il mittente viene informato dal riscontro che si è liberato dello spazio nel buffer, e reagisce così inviando un nuovo segmento. Si viene così a creare una situazione dove viene generato un nuovo pacchetto non appena si libera spazio sufficiente nel buffer, dando nuovamente origine ad una situazione di uso inefficiente del canale dato dal cattivo rapporto lunghezza pacchetto/dati contenuti.
Una soluzione è adottare la soluzione di Clark, con la quale si "inganna" il mittente specificando nei messaggi di riscontro che il buffer è ancora pieno (costringendolo così a bloccare l'invio) fino a che la coda non si sia svuotata per metà o a sufficienza per accogliere un segmento di dimensioni massime (MSS).
Un'altra soluzione consiste nel ritardare l'invio degli ACK (bloccando così il mittente) finché non si libera un certo numero di byte nel buffer. Il tempo massimo di ritardo dei riscontri va però calcolato accuratamente, per evitare che il mittente vada in timeout e ritrasmetta il pacchetto.