Sviluppo di tecniche per il trasporto di traffico satellitare multimediale in ambiente TCP/IP ed ATM

CAPITOLO 1      
Cenni sulla TCP/IP Internet Protocol Suite 
1.1  Introduzione 
Ciò che è comunemente noto come TCP/IP (dai nomi dei due standard principali 
della suite di protocolli), non è altro che un insieme di standard di rete che specifica i 
dettagli delle norme di comunicazione fra computer, oltre che una serie di 
convenzioni per l’interconnessione delle reti e lo smistamento del traffico. La suite, 
inizialmente prodotta nel 1983 dalla ricerca finanziata dalla DARPA (Defense 
Advanced Research Projects Agency: agenzia di progetti di ricerca avanzata della 
Difesa), è stata oggetto di modifiche ed aggiustamenti dei singoli protocolli. 
L’internetwork attualmente più famosa, nota con il nome di Internet, utilizza la suite 
TCP/IP. In figura 1-1 è riportata una schematizzazione della struttura della suite 
parallelamente all’architettura di Internet.  
Figura 1-1 Principali standard della TCP/IP Protocol Suite e architettura di 
Internet. 
File transfer protocol, FTP
Remote terminal protocol, TELNET
Simple mail transfer protocol, SMTP
Name server protocol, NSP
Simple network management protocol, SNMP
IP
TCP UDP
...
... Hardware
Interfaccia di rete
Internet
Trasporto
Applicazione
CAPITOLO 1    Cenni sulla TCP/IP Internet Protocol Suite 
 2
Segue una breve descrizione dei due protocolli principali. 
1.2  Cenni sul TCP 
Il TCP (Transmission Control Protocol: protocollo di controllo della trasmissione) 
[1] [2] è un protocollo connection-oriented, di applicabilità del tutto generale 
indipendentemente dalla suite di protocolli TCP/IP. E’ stato disegnato per inserirsi in 
una gerarchia stratificata di protocolli che supportano applicazioni internetwork. Al 
livello più basso, l’IP provvede alla consegna non affidabile dei datagrammi, che 
possono essere persi o alterati a causa di errori nella trasmissione, guasti 
dell’hardware della rete o quando il carico nella rete diventa troppo gravoso per le 
sue capacità.  
Caratteristiche principali del TCP: 
• Orientamento alla stream. Due programmi applicativi che utilizzano il TCP per il 
trasferimento di dati, inviano e ricevono dal protocollo di trasmissione una stream 
di byte (ottetti). Il TCP si preoccupa di consegnare al programma applicativo 
destinatario la stream senza errori e nella giusta sequenza. Per fare ciò, la stream è 
sezionata in pacchetti a discrezione del protocollo e indipendentemente da come 
Figura 1-2 Esempio di funzionamento dei riscontri 
cumulativi. 
Ricevuto segmento #3
Invio riscontro #4
Ricevuto segmento #5
Ricevuto segmento #6
Ricevuto segmento #4
Invio riscontro #4
Invio riscontro #4
Invio riscontro #7
Ricevitore
T
em
po
CAPITOLO 1    Cenni sulla TCP/IP Internet Protocol Suite 
 3
sia generata dal programma applicativo. Se, ad esempio, l’applicativo genera un 
ottetto alla volta, il TCP può raggruppare gli ottetti in un unico pacchetto di 
dimensione opportuna. La dimensione del pacchetto deve essere abbastanza 
grande da non caricare la rete con un eccessivo numero di byte. Se invece il 
programma applicativo sceglie di generare grandi blocchi di dati, il TCP può 
suddividerli in pacchetti più piccoli, in maniera tale da evitare, in caso di perdita 
di un pacchetto, la ritrasmissione dell’intero blocco di dati. Inoltre, è necessario 
che i programmi applicativi concordino in precedenza la struttura della stream ed 
il suo formato, prima di avviare una connessione. 
• Connessione di circuito virtuale. Prima di iniziare un trasferimento di dati, il TCP 
sta bilisce una connessione. Fatto ciò, il software del protocollo nelle due 
macchine informa i programmi applicativi che è stato creato un circuito virtuale. 
L’aggettivo virtuale è dovuto al fatto che le applicazioni hanno l’illusione che la 
connessione sia un circuito hardware dedicato, illusione che è provocata dalla pila 
di protocolli di livello più basso. 
• Connessione full-duplex. Le connessioni stabilite dal TCP consentono il 
trasferimento simultaneo di dati in entrambe le direzioni (full-duplex). Il 
vantaggio consiste nella possibilità, da parte del protocollo, di inviare le 
informazioni di controllo, che viaggiano nella direzione opposta al flusso di dati, 
insieme a pacchetti di dati e non come pacchetti separati, riducendo così il traffico 
nella rete (ciò prende il nome di piggy-backing). 
• Affidabilità e controllo di flusso. Queste due caratteristiche vengono 
implementate insieme, utilizzando un controllo di flusso di tipo finestra scorrevole 
di dimensione variabile con riscontri positivi e cumulativi (vedi figura 1-2). In 
questa maniera il protocollo ritrasmette eventuali pacchetti persi o errati, fornendo 
un servizio affidabile ai programmi applicativi di livello superiore, e, nello stesso 
tempo, implementa un efficace controllo del flusso mediante la finestra di 
dimensione variabile. 
1.2.1 Formato del segmento TCP 
L’unità di trasferimento per stabilire o terminare connessioni o per il trasferimento di 
dati e relativi riscontri tra due implementazioni del TCP viene chiamata segmento. In 
CAPITOLO 1    Cenni sulla TCP/IP Internet Protocol Suite 
 4
figura 1-3 è rappresentato il formato, con particolare attenzione all’intestazione che il 
protocollo aggiunge ad ogni segmento. I campi porta di provenienza e porta di 
destinazione contengono i numeri di porta del TCP che identificano i programmi 
applicativi alle estremità della connessione. Il campo numero sequenziale identifica 
nella stream di byte del trasmettitore, la posizione dei dati nel segmento. Il campo 
numero riscontro identifica il numero dell’ottetto che il ricevitore si aspetta di 
ricevere  successivamente. Quindi, questi due campi si riferiscono a dati che 
viaggiano in senso opposto (piggy-backing). Il campo offset dei dati indica dove 
cominciano i dati all’interno del segmento TCP specificando la dimensione 
dell’intestazione, poiché il campo opzioni è di dimensione variabile, rimanendo 
sempre un multiplo di 32 bit. Il campo bit di controllo serve per comunicare al 
destinatario come interpretare il segmento: ad esempio, il segmento può trasportare 
solo dati od essere utilizzato esclusivamente per un riscontro. E’ costituito da sei bit: 
• URG: il campo puntatore urgente è valido 
• ACK: il campo riscontro è valido 
• PSH: consegna i dati all’applicativo senza attendere altri segmenti 
• RST: reset della connessione 
• SYN: sincronizza i numeri di sequenza 
Figura 1-3 Formato del segmento TCP. 
Porta di provenienza Porta di destinazione
Dati...
...
Numero riscontro
Numero sequenziale
Checksum Puntatore urgente
Finestra
Opzioni (eventuali) Riempimento
0 4 10
HLEN Bit controlloRiservato
16 24 31
CAPITOLO 1    Cenni sulla TCP/IP Internet Protocol Suite 
 5
• FIN: il trasmettitore ha finito 
Il campo finestra specifica il numero di ottetti, cominciando da quello nel campo 
numero riscontro, che è disposto ad accettare (un altro esempio di piggy-backing, in 
quanto sono informazioni che riguardano la connessione in senso opposto). Il campo 
checksum serve per il controllo di errori in tutto il segmento. Tra le varie funzionalità 
del campo opzioni, esiste la possibilità di negoziare la dimensione massima del 
segmento (Maximum Segment Size). 
1.2.2 Setup di una connessione 
La creazione di una connessione avviene tramite una procedura nota come three-way 
handshake. In figura 1-4 è riportato un caso semplice di setup di una connessione. La 
numerazione a sinistra serve esclusivamente come riferimento e sono riportati i 
campi riscontro, numero sequenza e bit di controllo. Prima di commentare la figura, 
è necessario osservare che quando viene instaurata una connessione i protocolli nei 
due computer si accordano sul numero di sequenza iniziale. Nel punto 2 il TCP A 
comincia a trasmettere un segmento SYN, in cui specifica che la sequenza di ottetti 
che invierà sarà numerata a partire da 100. Nel punto 3, il TCP B invia un segmento 
SYN che contemporaneamente  riscontra il SYN ricevuto dal TCP A (piggy-
Figura 1-4 Setup di una connessione nel caso più semplice. 
    TCP A TCP B
<SEQ=100><CTL=SYN>
<SEQ=300><ACK=101><CTL
=SYN,ACK>
<SEQ=101><ACK=301><CTL=ACK>
<SEQ=101><ACK=301><CTL=ACK><DATA>
1. Disconnesso
3. Conn. stabilita
2. SYN inviata
1. In attesa
5. Conn. stabilita
4. Conn. stabilita
2. SYN ricevuta
3. SYN ricevuta
CAPITOLO 1    Cenni sulla TCP/IP Internet Protocol Suite 
 6
backing). Come osservato, il campo riscontro indica l’ottetto numero 101 che è il 
prossimo byte atteso, confermando la corretta ricezione degli ottetti precedenti (in 
questo caso nessuno). Nel punto 4 il TCP A risponde con un segmento vuoto 
contenente un riscontro per il SYN del TCP B, mentre nel punto 5 il TCP A comincia 
ad inviare dei dati. E’ interessante notare che il riscontro nel punto 5 è identico a 
quello nel punto 4, in quanto i riscontri non occupano spazio nel numero della 
sequenza. 
1.2.3 Controllo del flusso in dettaglio 
Per semplicità, nel seguito, ci si riferirà, relativamente ai riscontri, al numero del 
segmento e non al numero sequenziale della stream come specificato nello standard. 
A questo proposito va ricordato che il TCP utilizza i numeri sequenziali dei byte 
perché i segmenti non hanno lunghezza fissa e, nel caso in cui venga perso un 
segmento, il TCP potrebbe decidere di ritrasmettere i byte contenuti nel segmento 
assieme ad altri byte successivi in un segmento di dimensioni maggiori. 
1.2.3.1 Finestra scorrevole 
Il TCP utilizza un controllo del flusso di tipo finestra scorrevole: la dimensione della 
finestra coincide con il numero di segmenti inviati e non ancora riscontrati. Il 
protocollo gestisce tre puntatori associati ad ogni connessione, i quali definiscono 
una finestra scorrevole (vedi figura 1-5). Il puntatore A indica l’inizio della finestra, 
cioè il primo segmento che non è ancora stato riscontrato; il puntatore B separa, 
all’interno della finestra, i segmenti già trasmessi, da quelli ancora da inviare; il 
puntatore C, che indica la fine della finestra, indica l’ultimo segmento che può essere 
trasmesso senza la ricezione di ulteriori riscontri. Il protocollo invia senza ritardo 
tutti i segmenti all’interno della finestra, così il puntatore B si allontana rapidamente 
da A tendendo a coincidere con C. Il ricevitore deve avere una simile finestra per la 
ricostruzione della stream. Il protocollo mantiene un timer per ogni segmento. Nel 
caso in cui un segmento venga perso nella rete, quando il timer relativo a quel 
segmento raggiunge il valore del timeout (RTO: Retransmission TimeOut), il 
segmento viene ritrasmesso (rinizializzando il timer a zero). In questo modo il TCP 
realizza un servizio di trasporto affidabile. D’altra parte il meccanismo dei riscontri è 
CAPITOLO 1    Cenni sulla TCP/IP Internet Protocol Suite 
 7
un eccellente controllore del flusso temporizzando i pacchetti in base alle esigenze 
della rete (nell’ipotesi molto semplificativa che la capacità della rete sia costante nel 
tempo). In figura 1-6 viene visualizzata questa caratteristica. Supponiamo che 
trasmettitore e ricevitore, che appartengono a reti a larga banda distinte, siano 
collegati con un tratto a banda molto più stretta. La dimensione verticale rappresenta 
la bit rate del collegamento (spesso si usa impropriamente come sinonimo larghezza 
di banda), mentre la dimensione orizzontale rappresenta il tempo. I rettangoli 
ombreggiati rappresentano i pacchetti la cui dimensione è proporzionale all’area (bit 
rate x tempo = bit). Ovviamente la dimensione dei pacchetti è costante e quindi 
quando attraversano un collegamento con bit rate minore richiederanno più tempo 
per essere trasmessi. Se la sorgente trasmette ad un ritmo troppo alto per il collo di 
bottiglia, nella rete del ricevitore i pacchetti saranno spaziati dipendentemente dalla 
capacità del collegamento a banda stretta (Tpc = Tpd). Nell’ipotesi che il tempo per 
l’elaborazione dei pacchetti sia identico per tutti, i riscontri verranno generati con un 
intervallo Trd = Tpd. Nell’attraversamento del collo di bottiglia, i riscontri non 
verranno ulteriormente ritardati, in quanto la loro dimensione è minore di quella dei 
pacchetti di dati. Risulterà quindi Trm = Trc = Trd = Tpc, cioè i riscontri vengono 
ricevuti con la stessa frequenza con cui i pacchetti di dati attraversano la parte più 
critica del collegamento e, poiché, un nuovo pacchetto viene trasmesso dalla sorgente 
ogni volta che viene ricevuto un riscontro, i pacchetti verranno trasmessi con una 
frequenza tale da non creare congestione all’ingresso del collo di bottiglia. Sebbene 
un meccanismo del genere funzioni a regime, non è detto che con una finestra di 
dimensione fissa si raggiunga una condizione di regime. Per questo motivo sono state 
introdotte numerose modifiche, alcune delle quali accettate poi come standard [3] [4] 
[5] (Vedi 1.2.3.3 e seguito).  
Figura 1-5 Gestione della finestra scorrevole. 
10 11 121 2 3 4 5 6 7 8 9
A B C
Stream
 di dati
CAPITOLO 1    Cenni sulla TCP/IP Internet Protocol Suite 
 8
1.2.3.2 Timeout e stima del tempo di andata e ritorno 
Un problema delicato riguarda il valore di RTO, che, intuitivamente, dovrebbe valere 
per ogni pacchetto esattamente il suo RTT (Round Trip Time: tempo di andata e 
ritorno). Naturalmente è impossibile sapere a priori quanto varrà l’RTT di un 
pacchetto ed è quindi necessario stimarlo con la massima precisione. Un primo 
algoritmo [2] consiste nel valutare una stima di RTT (RTT*) che viene modificata 
ogni volta che viene ricevuto un riscontro; l’RTO si calcola poi a partire dall’RTT*. 
Chiamando RTTm il tempo di andata e ritorno misurato con l’ultimo riscontro si ha: 
( )
*
** 1
RTTmRTO
RTTgRTTgRTT m
×←
×−+×←
 
dove g e m sono due fattori moltiplicativi. Risulta 0 < g < 1 e m ≥ 1. Tanto maggiore 
sarà g, tanto più il nuovo campione sarà influente nella media; occorre quindi trovare 
un compromesso. Stessa considerazione per m, in quanto un m tendente ad uno 
renderebbe più efficiente la ritrasmissione, rischiando però in maniera maggiore di 
Tpc
Tpd
Trd
Trc
Trm
Trasmettitore Ricevitore
Figura 1-6 Controllo del flusso tramite i riscontri. 
CAPITOLO 1    Cenni sulla TCP/IP Internet Protocol Suite 
 9
ritrasmettere un segmento non perso. Prima di esaminare un algoritmo più efficiente 
occorre considerare un fenomeno noto come ambiguità del riscontro [1]. Ipotizziamo 
che in seguito alla scadenza di un timer venga ritrasmesso un segmento e che venga 
successivamente ricevuto un riscontro che confermi l’arrivo del segmento. In questa 
situazione non è possibile sapere se il riscontro è relativo alla prima o alla seconda 
trasmissione. Supponiamo di associare, ai fini del calcolo di  RTO, il riscontro con la 
prima trasmissione. Nel caso in cui il riscontro sia relativo alla seconda trasmissione, 
l’algoritmo incrementerà impropriamente RTT*. Se il fenomeno si ripete la stima di 
RTT rischia di aumentare indefinitamente. D’altra parte associare il riscontro con la 
ritrasmissione più recente potrebbe stabilizzare  RTT* ad un valore tale che la stima 
corretta sia leggermente superiore ad un suo multiplo. La soluzione utilizzata, 
proposta da Karn, prevede che i campioni di RTTm calcolati in base a segmenti 
ritrasmessi non vengano considerati per la stima di RTT. Nel caso di un aumento 
improvviso del ritardo nella rete, un’implementazione semplice di questa soluzione 
non indurrebbe mai un incremento di  RTT*. Per ovviare a questo problema, si adotta 
la strategia nota come backoff del timer che consiste nell’incremento arbitrario 
(tipicamente di un fattore 2) del  RTO nel caso di ritrasmissione di un segmento. 
Un’implementazione più efficace [4] del calcolo di  RTT* stima la varianza di RTT. 
Di seguito è riportato l’algoritmo. 
( )
**
*
2
**
1
**
*
s
sss
×+←
−×+←
×+←
−≡
mRTTRTO
Errg
ErrgRTTRTT
RTTRTTErr m
 
dove s* rappresenta una stima della deviazione media, che costituisce un limite 
superiore alla deviazione standard [4]. Per ragioni di semplicità di calcolo, g1 e g2 
sono inversi di multipli di 2. 
1.2.3.3 Ritardo dei riscontri 
Il ricevitore può ritardare l’invio del riscontro relativo ad un segmento [5] 
principalmente per due motivi: 
CAPITOLO 1    Cenni sulla TCP/IP Internet Protocol Suite 
 10
l può attendere di dover inviare un segmento dati unitamente al riscontro (piggy-
backing) in modo da occupare meno risorse di rete (un segmento dati può 
trasportare un riscontro senza l’uso di byte aggiuntivi); 
l può attendere di dover inviare un altro riscontro ed inviarne così solamente uno. 
1.2.3.4 Partenza lenta 
Con la dimensione fissa della finestra, se la connessione attraversa reti diverse è 
facile accumulare pacchetti nei router prima dei colli di bottiglia. Anche se questo 
fenomeno avviene solo inizialmente (in quanto, a regime, il numero di pacchetti in 
coda nel buffer del router rimane costante come è possibile vedere nella figura 
precedente), potrebbe essere sufficiente a far perdere dei pacchetti a causa della 
saturazione del buffer. Questo fenomeno dipende, ovviamente, da diversi fattori tra 
cui la dimensione della finestra. In una situazione del genere si può rischiare 
addirittura di trasmettere tutti (o quasi) i dati due volte [4]. Utilizzare una finestra a 
dimensione fissa può contribuire a creare i presupposti per il cosiddetto ‘collasso da 
congestione’, avvenuto per la prima volta nell’ Ottobre dell’86, in cui il throughput 
tra due siti a distanza di 360 metri precipitò da 32 Kbps ad appena 40 bps. La 
partenza lenta (Slow Start) aggiunge un’altra finestra al protocollo del lato 
trasmettitore, chiamata finestra di congestione (cwnd: Congestion WiNDow). Questo 
algoritmo funziona sul principio che i riscontri temporizzano la frequenza che la rete 
è in grado di sopportare. Quando viene stabilita una nuova connessione, la finestra di 
congestione viene inizializzata ad un segmento (o meglio al numero di ottetti che il 
ricevitore ha indicato come massima dimensione di un segmento). Ogni volta che 
viene ricevuto un riscontro, viene aumentata la sua dimensione di un segmento. Una 
regola fissa è che il trasmettitore invierà ogni volta un numero di segmenti non 
superiore al minimo tra la dimensione della finestra di congestione e quella indicata 
dal ricevitore nel campo finestra dei dati ricevuti da esso. In questa maniera il 
controllo del flusso è imposto dal trasmettitore, tramite la finestra di congestione, e 
imposto dalle esigenze del ricevitore grazie alla finestra indicata. E’ facile intuire che 
la partenza lenta induca una crescita esponenziale della dimensione della finestra. In 
seguito all’arrivo del primo riscontro, la finestra viene incrementata fino a due e 
vengono inviati due segmenti. Dopo un tempo pari a RTT ritorneranno due riscontri 
CAPITOLO 1    Cenni sulla TCP/IP Internet Protocol Suite 
 11
e la finestra raddoppierà di dimensione. Quindi la finestra raddoppia ogni RTT, ed il 
tempo necessario ad avere una finestra di dimensione W sarà dato dall’espressione 
RTT x LOG2(W) [4]. Quando la dimensione della finestra sarà tale da saturare la 
capacità massima della rete qualche buffer inizierà a scartare pacchetti e la finestra 
sarà regolata dagli algoritmi descritti in seguito. E’ interessante notare che nel caso 
peggiore, il trasmettitore saturerà esattamente la larghezza di banda dei colli di 
bottiglia e, alla ricezione dei riscontri, seguirà un raddoppio della dimensione della 
finestra e quindi la rete verrà investita con una quantità doppia dei pacchetti che è in 
grado di smaltire. Senza partenza lenta, quando ad esempio delle LAN a larga banda 
comunicano mediante collegamenti a banda molto più stretta, questi possono essere 
investiti da una quantità notevolmente superiore a due volte quella che riuscirebbero 
a smaltire.  
1.2.3.5 Anti-congestione 
L’algoritmo di anti-congestione (Congestion Avoidance) presuppone che la perdita di 
un pacchetto sia dovuta nella stragrande maggioranza dei casi ad una congestione 
nella rete e non ad un danneggiamento del pacchetto per errori di trasmissione (si 
ricordi che il TCP non usa riscontri negativi). Si ipotizza quindi che il mancato 
ricevimento di un riscontro sia dovuto alla perdita di un pacchetto causata dalla 
congestione di qualche collegamento. Ci sono due possibili indicatori: la ricezione di 
un riscontro duplicato o la scadenza di un timer. Per implementare l’anti-congestione 
insieme alla partenza lenta è necessaria un’ulteriore variabile chiamata soglia di 
partenza lenta (ssthresh: Slow Start THRESHold ). L’anti-congestione, a differenza 
della partenza lenta, garantisce un incremento più cauto della dimensione della 
finestra di congestione, in quanto l’incremento è di un segmento ogni volta che 
vengono ricevuti un numero di riscontri pari alla dimensione attuale della finestra. In 
questo modo, ad ogni RTT, la dimensione della finestra viene incrementata di uno 
con conseguente crescita lineare e non esponenziale come nel caso di partenza lenta. 
Per essere più precisi, la dimensione della finestra di congestione viene incrementata 
di una quantità pari a segsize x segsize / cwnd, dove segsize è la dimensione del 
segmento espressa in byte e cwnd è la finestra di congestione, anch’essa espressa in 
byte. Quando l’anti-congestione è implementata insieme alla partenza lenta, la 
CAPITOLO 1    Cenni sulla TCP/IP Internet Protocol Suite 
 12
variabile ssthresh serve da discriminatore tra questi due stati. Se cwnd è minore di 
ssthresh, allora il protocollo si trova nello stato di partenza lenta.  
1.2.3.6 Ritrasmisssione rapida 
Nel 1990 furono proposte modifiche all’algoritmo di anti-congestione [6]. La 
modifica di ritrasmissione rapida (Fast Retransmit) si basa sull’osservazione che, se 
il trasmettitore riceve un riscontro duplicato, significa che un segmento è stato 
ricevuto fuori sequenza, quindi il ricevitore non ha ricevuto  il segmento che 
attendeva, ma uno successivo. Il fenomeno potrebbe essere causato dal fatto che il 
segmento atteso abbia seguito un percorso più lungo oppure sia stato perso nella rete. 
Per evitare di ritrasmettere un segmento nel caso si verifichi la prima ipotesi, il 
trasmettitore attende la ricezione di più riscontri duplicati prima della ritrasmissione. 
In questa maniera si evita di dover attendere la scadenza del timer accorciando i 
tempi di attesa. Occorre osservare che il timer non diviene superfluo, in quanto la 
rete potrebbe essere talmente congestionata da perdere molti pacchetti e quindi 
potrebbe non venire ricevuto nessun riscontro (neanche duplicato). 
1.2.3.7 Ripristino rapido 
L’algoritmo di ripristino rapido (Fast Recovery) consiste nell’attivare l’anti-
congestione piuttosto che la partenza lenta, in seguito ad una ritrasmissione rapida. 
Ciò permette un throughput elevato nel caso di congestioni moderate della rete. Il 
motivo risiede nel fatto che se vengono ricevuti riscontri duplicati significa che solo 
un pacchetto (nel caso migliore) è stato perso, ma comunque dei segmenti 
continuano a fluire nella connessione abbandonando la rete. Attivare la partenza 
lenta sarebbe una maniera troppo brusca per ridurre il traffico nella rete. 
1.2.3.8 L’algoritmo 
In figura 1-7 è riportato uno schema illustrativo semplificato del funzionamento del 
controllo di flusso del protocollo secondo lo standard [3]. Appena stabilita una nuova 
connessione vengono inizializzate le variabili 
l cwnd = 1segmento (MSS in byte) 
CAPITOLO 1    Cenni sulla TCP/IP Internet Protocol Suite 
 13
l ssthresh = dimensione della finestra indicata dal ricevitore (al massimo 216 = 
65536 byte) 
Occorre definire una nuova variabile che prende il nome di finestra corrente 
(currw: CURRent Window), che non è altro che il minimo tra cwnd e la finestra 
indicata dal ricevitore. Il TCP si trova in partenza lenta e per ogni riscontro 
ricevuto viene incrementata cwnd di una unità. Possono accadere tre eventi: 
l il valore di cwnd è maggiore o uguale di ssthresh. Il protocollo entra in anti-
congestione. 
l un timer raggiunge il valore  RTO. Viene allora ritrasmesso il segmento, si pone 
cwnd = 1 e si pone ssthresh pari a metà  currw, in modo che il protocollo sia 
sempre in partenza lenta ed entri in anti-congestione prima di ricevere il segnale 
di aver congestionato la rete . 
Figura 1-7 Le lettere indicano eventi che si manifestano ed i numeri le 
azioni intraprese dal protocollo. A: cwnd�ssthresh, B: riscontro corretto, C: 
timer scaduto, D: 3 riscontri duplicati, E: currw riscontri corretti, F: 
riscontro duplicato; 1: cwnd=cwnd+1, 2: ritr. segm. ssthresh=currw/2 
cwnd=1, 3: ritr. segm. ssthresh=currw/2 cwnd=ssthresh+3, 4: cwnd=ssthresh. 
SLOW
START
CONGESTION
AVOIDANCE
FAST
RECOVERY
A,#
F,1
B,4
E,1
C,2
D,3
C,2B,1
D,3