Sei sulla pagina 1di 41

Appunti di Reti di Telecomunicazioni L-S

(versione 0.9)

Ingegnere Pazzo
http://ingegnerepazzo.wordpress.com/

12 febbraio 2009
2
Indice

1 Il protocollo TCP: generalità 5


1.1 Il segmento TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Macchina a stati finiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Three-way handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 Chiusura della connessione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Lo svolgimento del dialogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Retransmission Time-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Lo stato enstablished . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Messaggi di conferma (ACK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Il protocollo TCP: controllo del flusso 13


2.1 Generalità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Meccanismo a finestra scorrevole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Silly Window Syndrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Algoritmo di Nagle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Controllo di congestione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Alcune definizioni ed evoluzione della CW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Alcune approssimazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 Un esempio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Altri aspetti del protocollo: algoritmi migliorativi . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.1 Fast recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.2 Fast retransmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.3 Reno e New Reno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Modelli analitici per le prestazioni del TCP 25


3.1 Ricerca di modelli matematici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Throughput e goodput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Modello periodico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1 ACK ritardati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Perdite aleatorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.1 Modello TD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.2 Modello TD+TO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.3 Modello TD+TO+AW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Modelli a confronto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6 Latenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6.1 Finestra a dimensione fissa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.2 Finestra evolvente (dinamica) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3
4 INDICE
Capitolo 1

Il protocollo TCP: generalità

Il protocollo TCP è parte integrante dello strato 4 (trasporto) della pila OSI e ha il compito di svin-
colare gli strati superiori dai problemi di rete. È un protocollo di tipo connection-oriented (al contrario
dell’UDP che è connection-less) e gestisce una connessione end-to-end (punto-punto) e full-duplex (bidi-
rezionale); prevede inoltre procedure per l’instaurazione della connessione, il controllo del suo corretto
andamento e la chiusura. Tutte le informazioni necessarie al corretto svolgimento dell’algoritmo TCP
sono contenute nel TCB (transmission control block). L’interfaccia con le applicazioni, invece, non è definita
a priori e fondamentalmente dipende dal sistema operativo utilizzato dall’utente.
Il TCP garantisce la correttezza nella consegna dei dati utilizzando un protocollo a finestra scorrevole
(Sliding-Window) basato su:

• numerazione sequenziale dei dati;

• conferma esplicita da parte del ricevitore;

• ritrasmissione dei dati non confermati.

1.1 Il segmento TCP


Il TCP incapsula i dati in pacchetti chiamati segmenti. Il segmento TCP prevede un header standard
di 20 byte, un header variabile con varie opzioni, un payload di dimensione variabile contente i dati del-
l’applicazione. Ogni segmento può avere una dimensione massima pari a MSS (Maximum Segment Size) e
tipicamente contiene - oltre ai dati - informazioni come la porta sorgente, la porta destinazione, il numero
di sequenza, l’acknowledge-number, un checksum per controllare se vi sono errori, alcuni bit per settare le
opzioni (URG per considerare il campo Urgent Pointer, ACK considerare il campo Acknowledge, RST per
resettare la connessione, SYN per sincronizzare i numeri di sequenza, FIN, per indicare la fine dei dati,
PSH per la funzione di push, etc. . . ).
L’MSS dipende dall’implementazione e normalmente è configurabile: il valore massimo che può as-
sumere è pari a 216 − 20(header TCP) − 20(header IP) = 65495 byte, cioè pari alla dimensione del payload
IP meno le intestazione, ma per l’Ethernet (che è il caso sul quale ci soffermeremo) è molto inferiore in
quanto deve rispettare i 1500 byte imposti da tale tecnologia.

1.2 Macchina a stati finiti


In figura 1.1 vediamo il diagramma che illustra il funzionamento del protocollo TCP. Le linee trat-
teggiate indicano un’azione tipica di un server, le linee nere le azioni tipiche dei client e quelle chiare gli
eventi ‘inusuali’. Sopra ogni freccia è indicata inoltre la {causa}/{effetto}. Esaminiamo insieme la figura:
cosa succede fra un client e un server che vogliono iniziare a comunicare? Partendo da CLOSED e seguen-
do la linea nera, il client invierà un SYN al server per poter sincronizzare con esso il numero di sequenza.
Il server (che parte da LISTEN) è - appunto - in ascolto e aspetta che qualcuno chieda i suoi servigi così,
quando gli arriva il SYN da parte del client, invia un SYN+ACK per far sapere al client che ha ricevuto la
sua richiesta (siamo ora nello stato SYN RECIEVED). Il client riceve la conferma del server e manda a sua

5
6 CAPITOLO 1. IL PROTOCOLLO TCP: GENERALITÀ

Figura 1.1: La macchina a stati finiti che implementa il TCP

volta una conferma (un SYN+ACK): a questo punto il server non richiede altre conferme1 ed entrambi
i comunicanti finiscono nello stato ENSTABLISHED (in verde). Quello illustrato fin’ora è il cosiddetto
three-way handshake (‘stretta di mano a tre tempi’) e, alla prova dei fatti, si è dimostrato un metodo ab-
bastanza robusto per instaurare una connessione (v. paragrafo 1.2.1). Chiaramente, durante queste fasi,
possono accadere eventi come l’apertura simultanea (freccia nera da SYN SENT a SYN RCVD) o il non
completamento del TWH (freccia nera da SYN RCVD a LISTEN). La parte inferiore del diagramma a stati
si riferisce invece alla chiusura della connessione: la chiusura può essere passiva (da parte del server, che
riceve il FIN e risponde con ACK) oppure attiva (da parte del client).

• CASO 1: il client (C) vuole chiudere così invia un FIN; S risponde con un ACK ed, eventualmente,
continua ad inviare dati perché la sua direzione è ancora aperta; quando si stufa pure lui invia un
FIN e il C, che è in stato FIN WAIT 2, risponde con un ACK.
1 Se si continua a confermare all’infinito non si trasmette nulla!
1.2. MACCHINA A STATI FINITI 7

• CASO 2: entrambi vogliono chiudere. Inviano contemporaneamente il FIN (C va in CLOSING e S,


dopo la conferma, in CLOSE WAIT), si scambiano gli ACK e poi chiudono.

• CASO 3: il client vuole chiudere e il server si accorge di voler fare lo stesso. Tutto funziona come
nel caso 1, tranne per il fatto che S non vuole spedire dati e in una botta sola invia sia l’ACK che il
FIN.

Si noti che il client rimane per un po’ nello stato di time wait, utile per fare sì che i pacchetti dell’attuale
connessione si estinguano onde evitare la sovrapposizione di più incarnazioni (v. par 1.2.1).
Perché tutta questa serie di conferme e riconferme? Il fatto è che, se il mezzo di comunicazione è
inaffidabile, è impossibile avere uno scambio di informazioni con conferma certa in quanto i messaggi, sia
quelli contenenti dati che quelli contenenti informazioni di servizio, possono effettivamente perdersi nella
rete.

1.2.1 Three-way handshake


Per quanto riguarda l’apertura di una connessione, si è scelto di fermarsi alla conferma della conferma:
il three-way handshake, grazie a questa convenzione, è in grado di gestire situazioni di perdita, duplicazione
o ritardo dei pacchetti. In tabella 1.1 si illustra il procedimento con particolare riferimento ai numeri di
sequenza. Per semplicità indicheremo i due colloquianti con CLIENT e SERVER (ma, per generalità, si
possono pensare tali due computer come due calcolatori qualsiasi A e B).

Chi parla? SIN bit ACK bit SeqN AckN Chi parla?
CLIENT 1 0 x -
1 1 y x+1 SERVER
CLIENT 0 1 x y+1
CLIENT 1 0 x+1 y+1

Tabella 1.1: Numeri di sequenza nel TWH

Si noti che il primo pacchetto dati ha numero di sequenza uguale all’ACK precedente!
Eventi imprevisti o inusuali:

• Instaurazione multipla: A e B vogliono connettersi ed inviano entrambi una richiesta d’apertura. Il


primo che risponde a questa richiesta ’fa le veci del server’ (nel senso illustrato dalla tabella 1.1: qui,
più che mai, la distinzione client/server è poco significativa).

• Pacchetti d’apertura ritardatari: uno dei due tentativi di connessione viene inibito tramite l’atti-
vazione del bit RST.

• Problema delle ’incarnazioni’: A e B stanno parlando, ma A viene riavviato per qualche motivo; B
rimane attivo su quella connessione, ma se A vuole riprendere la conversazione dovrà stabilirne una
nuova. Questo potrebbe dar adito a diverse ’incarnazioni’ della medesima connessione logica. Il TCP
risolve questo problema riallineando i numeri di sequenza e ristabilendo il parallelismo: uno dei due
host, infatti, crederà che la connessione precedente sia ancora attiva e invierà all’altro dei numeri di
sequenza palesemente sbagliati, cosicché la vecchia connessione verrà annullata con l’attivazione del
bit RST.

1.2.2 Chiusura della connessione


Il TCP ce la mette tutta per garantire che, alla chiusura della connessione, non vengano persi dati. An-
che questo aspetto, in realtà, non è così immediato da affrontare visto che la rete può risultare inaffidabile:
il TCP però ci prova scegliendo una chiusura unidirezionale e indipendente delle due direzioni. L’host
che intende terminare la trasmissione invia un segmento con il bit FIN a 1 e, ricevuto l’ACK, considera
chiuso il dialogo. Se l’ACK non arriva, il mittente del FIN lascia comunque la connessione.
Questa procedura ha il pregio di funzionare anche se i due host tentano contemporaneamente di
chiudere la connessione: in tal caso, infatti, la chiusura avviene in maniera esattamente simmetrica da
ambo le parti.
8 CAPITOLO 1. IL PROTOCOLLO TCP: GENERALITÀ

1.3 Lo svolgimento del dialogo


Il protocollo TCP deve saper gestire situazioni non banali del tipo:

• i ricevitori potrebbero avere caratteristiche fra loro diverse o essere addirittura delle macchine
completamente diverse;

• la rete non garantisce l’arrivo dei dati in sequenza;

• la congestione della rete è qualcosa di estremamente variabile e il ritardo di propagazione non è mai
costante;

• possono esserci, in maniera aleatoria, aumenti/diminuzioni della banda;

• etc. . .

Per risolvere questi problemi, il TCP utilizza un protocollo a finestra scorrevole (di cui parleremo nel
paragrafo ...) e utilizza quattro contatori:

• RTO (retransmission time-out): vedi paragrafo 1.3.1;

• persist timer: se un ACK viene perso, può capitare che i due host comunicanti rimangano l’uno
in attesa dell’altro: il ricevitore aspetta i nuovi dati, mentre il trasmettitore aspetta di ricevere la
conferma in grado di allargargli la finestra. Per prevenire questa forma di deadlock è necessario che
il trasmettitore utilizzi un persist timer che interpelli il ricevitore in maniera periodica;

• keep-alive timer: non necessariamente, se è attiva una connessione fra due host, vi è un trasferimento
di dati fra sorgente e destinazione; se la connessione rimane però dormiente per molto tempo, è
probabile che uno dei due colloquianti si sia disattivato ed è opportuno eliminarla del tutto per lib-
erare le risorse da essa occupate. Allo scadere del keep-alive timer, uno dei due host invia all’altro un
messaggio di prova; se riceve risposta allora il timer viene resettato mentre, se tutto tace, vengono
mandati altri 9 messaggi di prova con un intervallo pari a 75 secondi l’uno dall’altro. Presumi-
bilmente, se anche questi 9 messaggi non ricevono risposta, l’altro calcolatore dev’essere ’caduto’
quindi la connessione viene interrotta;

• time wait: al termine della chiusura della connessione, il client si ferma nello stato time wait per un
tempo pari a 2 · MSL 2 , allo scadere del quale - se nulla è accaduto, lo stato della connessione passa
a CLOSED. Questo timer vuole garantire l’estinzione di segmenti appartenenti a precedenti incar-
nazioni, onde evitare ambiguità con future riconnessioni fra le stesse porte degli stessi calcolatori
(vedi paragrafo 1.2.1).

1.3.1 Retransmission Time-Out


Ogni volta che si trasmette un segmento viene fatto partire l’RTO: se il timer scade prima che sia
stato ricevuto l’ACK si assume che il segmento non sia stato ricevuto. L’RTO dev’essere dimensionato
in relazione al tempo di andata e di ritorno (Round Trip Time, RTT) ma, soprattutto, deve poter essere
determinato in modo dinamico per meglio adattarsi alle condizioni, sempre mutevoli, della rete. L’RTT è
infatti aleatorio e dipende dalla maggiore o minore congestione della rete; l’RTO invece è deterministico,
nel senso che viene ricavato tramite formule matematiche all’interno delle quali, tuttavia, fa comparsa
l’RTT medio. Per il calcolo si utilizzano tre variabili:

• eRTT: stima del valore medio del RTT basato sulle misurazioni passate;

• sRTT: misurazione del RTT relativo all’ultimo segmento confermato;

• vRTT: è una stima della variabilità di RTT.


2 MSL = Maximum Segment Lifetime, noto a priori (nell’RFC 793 è fissato a 2 minuti).
1.3. LO SVOLGIMENTO DEL DIALOGO 9

Estimated Round Trip Time (eRTT)


La prima misurazione della stima del RTT (parametro eRTT), all’istante n = 0, viene effettuata
semplicemente traendo l’ultima misurazione

eRTT (0) = sRTT (0)

Quelle successive vengono invece determinate dando un certo peso (1 − α) alla stima dell’istante prece-
dente (n − 1) e un altro peso (α) al valore ricavato dall’ultimo segmento confermato (istante n):

eRTT (n) = (1 − α) · eRTT (0) + α · sRTT (1)

Il parametro α (valore suggerito: 1/8 = 0, 125) indica quanto peso viene dato al passato (cioè alla mis-
urazione dell’istante n − 1): tanto più è piccolo e tanto più faremo riferimento al passato piuttosto che
alla misurazione corrente. Tale procedura di calcolo dell’eRTT viene detta Exponential Weighted Moving
Average: Exponential perché il peso dei valori passati diminuisce in modo esponenziale a favore dei valori
recenti3 ; Weighted perché il parametro α ci permette di fissare il peso dei campioni più recenti; Moving per
la sua natura dinamica.

Parametro vRTT
Passiamo infine al parametro vRTT che, come abbiamo già detto, è una stima della variabilità del RTT.
Il valore di vRTT all’istante 0 è canonicamente4 pari a

sRTT (0)
vRTT (0) =
2
Per le successive misurazioni, invece, si usa la seguente regola:

vRTT (n) = (1 − β) · vRTT (n − 1) + β |eRTT (n − 1) − sRTT (n)|

Il parametro β è compreso tra 0 e 1 e ha valore consigliato pari a 1/4 = 0, 25: questo significa che viene
dato più peso al passato rispetto che al presente.

RFC 793 (1981)


L’RTO viene calcolato come segue:

RTO = min[UB, max[ LB, (γ · eRTT )]]

UB è il valore massimo ammissibile per RTO5 , mentre LB è il corrispondente valore minimo6 ; γ, invece,
è un parametro compreso fra 1 e 2. Come è facile dedurre, l’RTO sarà compreso fra LB e UB; il calcolo
dell’eRTT, infine, può essere sovrastimato tramite il parametro β.

RFC 2988 (2000): algoritmo di Jacobson


Col passare del tempo si è scoperto che la convenzione imposta dall’RFC 793 era migliorabile; Jacobson
ha quindi proposto di considerare anche le fluttuazioni della situazione (rappresentate dal parametro
vRTT):
RTO = max[ LB, eRTT + max[ G, 4vRTT ]]
3 Si ha infatti
eRTT (1) = (1 − α) · eRTT (0) + α · sRTT (1)
eRTT (2) = (1 − α)2 · eRTT (0) + (1 − α) α · sRTT (1) + α · sRTT (2)
eRTT (3) = (1 − α)3 · eRTT (0) + (1 − α)2 α · sRTT (1) + (1 − α) α · sRTT (2) + α · sRTT (3)
...
n
eRTT (n) = (1 − α)n · eRTT (0) + ∑ (1 − α)n−i α · sRTT (i )
i =1
4 Non possiamo fare alcuna stima visto che siamo all’inizio della trasmissione, quindi usiamo come riferimento un valore standard.
5 1 minuto.
6 1 secondo.
10 CAPITOLO 1. IL PROTOCOLLO TCP: GENERALITÀ

LB è ancora il valore minimo ammissibile per l’RTO, mentre G è un’unità di misura del tempo presa
come parametro. La relazione soprascritta indica che, se la linea è instabile e ballerina, è opportuno
sovradimensionare l’RTO; in caso contrario, una buona stabilità della linea incoraggerebbe mantenere
l’RTO il più vicino possibile a eRTT (tendiamo a ’fidarci’ della linea). Si faccia riferimento alla figura 1.2.

Linea stabile → RTO ≈ eRTT


Linea instabile → RTO >> eRTT

Figura 1.2: Evoluzione dell’RTO secondo i due RFC illustrati. Il risultato è migliore tanto più si è vicini alla linea
rossa. Si noti che Jacobson ha dei grossi vantaggi quando la linea è stabile, mentre si tiene dalla parte del
sicuro quando non lo è

Misurazione di sRTT

Generalmente tale parametro si ricava come multiplo di intervalli di 500 ms; il TCP mantiene attiva
una sola misurazione alla volta quindi, in caso di trasmissioni consecutive a breve distanza, solamente la
prima valuta l’sRTT (figura 1.3).
Un inconveniente comune (figura 1.4) è quello che potrebbe avvenire quando vi è ritrasmissione dei
dati (in seguito alla perdita di un pacchetto o allo scadere dell’RTO): per questo motivo in caso di ri-
trasmissione l’sRTT non viene misurato e viene invece rilevato al successivo segmento senza ritrasmissione
(algoritmo di Karn/Partridge).

Exponential back-off

Una volta che avviene una ritrasmissione per mancanza di risposta, può aver senso dare un tempo
maggiore al ricevitore di rispondere: per questo motivo, ad ogni ritrasmissione, il TCP raddoppia l’RTO
fino al raggiungimento di un valore massimo.
1.4. LO STATO ENSTABLISHED 11

Figura 1.3: Misurazione dell’sRTT

Figura 1.4: Ambiguità nel calcolo dell’sRTT

1.4 Lo stato enstablished


Per avere massima flessibilità si sceglie di assegnare un numero non ai segmenti bensì ai singoli byte
trasportati dai segmenti: si comincia a numerare da un numero x scelto all’atto dell’apertura della con-
nessione7 e la conferma di avvenuta ricezione viene data mettendo nel campo Ack. number il numero
del byte successivo all’ultimo ricevuto (cioè del primo byte che ci si aspetta di ricevere). Quali possibili
inconvenienti possono sopraggiungere:
• segmenti duplicati: un segmento con numero di sequenza X viene duplicato dalla rete;
• segmenti ritardati: un segmento con numero di sequenza Y > X arriva prima del segmento X;
• ambedue le cose: un segmento X viene duplicato e una delle due copie viene confermata, mentre
l’altra arriva solo successivamente8 . In tal caso la trasmissione continua e, una volta che si è esaurito
lo spazio di numerazione, vengono riciclati numeri già utilizzati9 : questo significa che prima o
poi sarà generato un altro pacchetto avente numero di sequenza X (ma diverso da quello del giro
precedente): se entrambi gireranno per la rete avremo due segmenti con stessa intestazione ma
contenuto diverso! Il peggio che può capitare, in questa caso, è che la copia ritardata (quella del giro
prima) arrivi prima dell’altra e venga interpretata come segmento valido.
Osserviamo ora la figura 1.5: sulle ordinate compare il numero di sequenza, mentre sulle ascisse il
tempo. Le rette nere spesse rappresentano l’andamento crescente del numero di sequenza col passare del
7 ISN (Initial Sequence Number) dev’essere casuale, uguale per tutti e scelto per garantire che non vi sia duplicazione nell’uso dei

numeri di sequenza.
8 Quello che stiamo per dire vale anche nel caso in cui un host venga riavviato a causa di un problema e rimanga attiva una

vecchia incarnazione della connessione.


9 Questo è inevitabile, ma dovremmo prima essere sicuri che in rete non esistano più vecchi segmenti numerati con tali numeri.

Per questo si fissa un massimo tempo di vita dei segmenti (MSL, Maximum Segment Life), noto a priori: nel 1973 tale parametro
veniva fissato a 2 minuti, ma con l’avvento di reti sempre più veloci si è reso necessario abbatterlo notevolmente.
12 CAPITOLO 1. IL PROTOCOLLO TCP: GENERALITÀ

tempo: la loro diversa pendenza dipende dalla velocità della connessione (più lo scambio di messaggi
è rapido, più velocemente aumenta il SeqN e più pendente è la retta); il segmento orizzontale (MSL) si
riferisce all’esistenza in vita di un pacchetto avente numero di sequenza pari a quello cui si era arrivati
prima del crash della connessione C1. La connessione C2 riparte e, in entrambi i casi, finiamo per cadere
nella trappola dei ’numeri doppi’: l’esempio ci mostra che questo può accedere sia se l’ISN (Initial Sequence
Number) viene fissato a zero di default (a sinistra), sia se viene posto pari a un contatore10 (a destra).
L’unico modo per evitare questo inconveniente è quello di attendere un MSL prima di aprire una nuova
connessione TCP (TCP quiet time).

Figura 1.5: Duplicazione dei numeri di sequenza

1.5 Messaggi di conferma (ACK)


Gli ACK, ovvero i messaggi di conferma, sono cumulativi e vengono portati ’a cavalluccio’ (piggyback-
ing) di un normale messaggio TCP11 , che può normalmente contenere dati. La conferma, di default, è
esplicita e quindi il ricevitore trasmette un ACK per ogni segmento ricevuto: può però essere conveniente
ripensare questo meccanismo e scegliere di inviare ACK ritardati o cumulativi al fine di diminuirne il
numero. Si potrebbe, ad esempio, inviare un ACK ogni due segmenti utilizzando il sistema della finestra
scorrevole (protocollo ARQ).
Sia ora WT la finestra di trasmissione e WR la finestra di ricezione, con WT e WR minori dello spazio
di numerazione del TPC (M = 232 ); se il ricevitore ha ricevuto fino a SeqN = N, allora si attenderà
un segmento con SeqN = N + 1 mod M: se non riceve quello che si aspetta12 , bensì un segmento con
SeqN > N o < N, allora il ricevitore interpreterà quello che gli arriva rispettivamente come un segmento
fuori sequenza (numero di sequenza troppo alto) o come un duplicato ritardato (numero di sequenza
appartenente ’al passato’). Nel primo caso il ricevitore memorizzerà il segmento, purché esso stia all’in-
terno della sua finestra WR , ritrasmetterà l’ultima conferma inviata (ACK N + 1) e, una volta che avrà
ricevuto tutta la sequenza completa (compreso il segmento N + 1), comunicherà direttamente ACKX + 1
sbloccando la sua finestra; nell’altro caso scarterà il pacchetto considerandolo un doppione. Quanto det-
to fin’ora funziona purché il ricevitore sia dotato di memoria: chiaramente conviene memorizzare meno
cose possibili quindi, finché non accade nulla di imprevisto, ogni pacchetto confermato in ordine corretto
cancella il corrispondente segmento in memoria e fa scorrere la finestra.

10 Inquest’ultimo caso ISN è funzione del tempo utilizzando un sistema di conteggio a 32 bit con incremento ogni 4 microsecondi.
11 Quel che fa testo è il bit ACK, che se è pari ad 1 ha significato di conferma.
12 Ad esempio perché la rete ha perso o ritardato i pacchetti che doveva consegnare.
Capitolo 2

Il protocollo TCP: controllo del flusso

2.1 Generalità
La velocità del trasmettitore potrebbe, in generale, essere molto diversa da quella del ricevitore, ma non
per questo uno dei due colloquianti ha licenza di saturare l’altro: per tal motivo si utilizza un meccanismo
a finestra scorrevole (ARQ). Il corretto dimensionamento della finestra deve tuttavia tenere conto - oltre
che della velocità della rete - anche delle velocità d’elaborazione di trasmettitore e ricevitore, nonché
della quantità di memoria posseduta da ciascuno di essi. Questo problema potrà sembrare anche banale,
ma non lo è affatto: il trasmettitore, a priori, non sa proprio un bel niente sul ricevitore e l’aleatorietà
della congestione in rete non aiuta a prendere delle decisioni senza uno straccio d’informazione. Per
potersi conoscere, i due host devono quindi potersi comunicare l’un l’altro le dimensioni della memoria
di ricezione: per questo motivo, nell’intestazione del pacchetto TCP, è contenuto il campo Advertised
Window (AW).

2.2 Meccanismo a finestra scorrevole


La dimensione della finestra viene messa appunto dinamicamente: non ha infatti senso una finestra di
dimensione fissa, dovendo noi obbligatoriamente adeguarci di volta in volta alle situazioni del momento.
Per poter dimensionare la finestra, abbiamo bisogno di:

• dati provenienti dal ricevitore (parametro AW);

• dati sulla congestione della rete (parametro CW, Congestion Window, ricavati tramite una stima
effettuata dal TCP.

Figura 2.1: Il meccanismo a finestra fra segmenti ricevuti e segmenti non trasmessi.

La dimensione della finestra1 è pari al massimo tra AW e CW:

W = max( AW, CW )

Mettiamo ora che un ipotetico trasmettitore sia molto più lento di un ricevitore, che quindi viene
saturato: una volta che il buffer di ricezione si riempie, AW va a 0 e il trasmettitore blocca l’invio di dati.
1 La dimensione della finestra può essere data in byte o in segmenti: noi preferiremo generalmente questa seconda scelta, in-

dicando con w la finestra in byte e W la finestra in segmenti. Si noti che si ha w = MSS · W, dove MSS è il Maximum Segment
Size

13
14 CAPITOLO 2. IL PROTOCOLLO TCP: CONTROLLO DEL FLUSSO

La ripresa della trasmissione avviene quando il processo ricevente legge dal buffer e spedisce un AW > 0.
Questo meccanismo nasconde però un’insidia: se

• il trasmittente invia messaggi fino alla ricezione di AW = 0 e, a quel punto, sospende l’invio,

• il ricevitore invia un messaggio con AW = 0 ma non ha nulla da dire e quindi non trasmette nulla,

allora la finestra non verrà mai sbloccata perché il ricevitore non riesce a spedire alcun messaggio con
AW > 0. Siamo in pieno deadlock; per questo il TCP permette che sia sempre possibile inviare un segmento
di 1 byte anche se AW = 0: dal momento che l’Advertised Window è pari a zero, infatti, parte il persist timer
allo scadere del quale si invia un segmento di un byte (SeqN = X + 1, dove X è il numero di sequenza
dell’ultimo pacchetto correttamente trasmesso) avente lo scopo di sbloccare la finestra. Se poi il ricevitore
risponde con ACK = X + 2 e AW > 0, la trasmissione potrà continuare; in caso contrario, se cioè il buffer
è invece ancora irrimediabilmente pieno, verrà spedito ACK = X + 1 e AW = 0, così che il persist timer,
che questa volta avrà durata doppia (PT 0 = 2PT) ricomincerà a contare.

2.2.1 Silly Window Syndrome


Questo meccanismo va bene fino a un certo punto: se non arrivano altri ACK, la finestra avrà sempre
dimensione 1 e la trasmissione sarà lentissima. Stesso risultato abbiamo se l’applicazione è lenta ad
accettare i dati e legge un byte alla volta, comunicando una dimensione di finestra sempre troppo piccola.
Quest’ultima evenienza prende il nome di silly window syndrome (abbreviato in SWS):

• il buffer di ricezione è pieno (AW = 0);

• l’applicazione (del ricevitore) legge un byte, libera altrettanto spazio dal buffer e trasmette AW = 1;

• il trasmettitore riceve tale indicazione e, non potendo far altro, manda un solo byte;

• il buffer di ricezione si riempie di nuovo e siamo daccapo.

In questa spiacevole situazione inviamo un carattere alla volta e AW continua ad oscillare tra 0 e 1;
fortunatamente anche quest’inconveniente è risolvibile, grazie all’algoritmo di Nagle (v. paragrafo 2.2.2).

2.2.2 Algoritmo di Nagle


Quando siamo in deadlock per colpa della SWS (paragrafo 2.2.1) bisogna trovare il modo di aumentare
la dimensione del messaggio (dev’essere più grande di 1 byte, cioè di un ’tinygram’, come si dice in gergo):
è infatti stupido inviare un datagrammetto con 90% header e 10% dati; ciò si può realizzare forzando il
trasmettitore a inviare un nuovo segmento se e solo se è vera una delle seguenti condizioni2 :

• il segmento ha dimensioni pari a MSS;

• il segmento è di dimensioni pari almeno alla metà del valore di AW (se proprio non riesco ad inviarti
tutto, ti invio almeno metà di quello che potresti);

• non vi sono ACK pendenti ed è possibile trasmettere tutto ciò che è in attesa nel buffer di trasmis-
sione.
2 Wikipedia spiega lo stesso problema con altre parole e aiuta a fare chiarezza.

Nel caso in cui il processo di scrittura dei dati nel buer TCP del mittente sia molto lento, il protocollo spedirà una serie di pacchetti
contenti una quantità di dati molto bassa, con un uso ineciente 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 buer 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 buer per poi venire spediti in un unico blocco alla ricezione dell'ACK dell'ultimo pacchetto trasmesso
o quando si raggiunge la massima dimensione ssata 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 buer 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ù eciente delle risorse del
canale che nel caso in cui l'algoritmo non venga utilizzato.
2.3. CONTROLLO DI CONGESTIONE 15

L’effetto dell’algoritmo di Nagle è che si può avere un solo segmento pendente per il quale non si è
ricevuto l’ACK; di conseguenza, più veloci arrivano gli ACK e più velocemente si trasmette. L’effetto col-
laterale, invece, è quello che si tende a ritardare i dati nel buffer di trasmissione e, per alcune applicazioni,
questo potrebbe essere non accettabile: di conseguenza l’algoritmo di Nagle è disabilitabile.

2.3 Controllo di congestione


Come abbiamo avuto modo di vedere, W è limitato superiormente da AW e CW; rimane da chiarire
come quest’ultimo parametro venga determinato. Ebbene, il TCP cerca di adattare la dimensione del-
la finestra in funzione delle condizioni di congestione della rete, aumentandola quando si ricevono
correttamente gli ACK e restringendola quando si verificano perdite: da qui l’esistenza del parametro
CW.
Avendo a disposizione una banda B (misurata in byte/s), il massimo throughput si ottiene quando il
protocollo a finestra non limita la velocità di scambio dei dati, cioè quando nel famoso schema con le due
aste verticali rappresentanti client e server non vi sono buchi e ogni momento diventa un istante valido
per trasmettere dati nuovi. Se siamo in questo caso la finestra dev’essere più grande di:

wid ≥ RTT · B → In byte


wid
Wid = → In segmenti
MSS
w W
Massimo throughput → S = (byte/sec) = (segmenti/sec)
RTT RTT
In questo caso si utilizza il massimo della capacità disponibile; gli altri due casi, quelli cioè in cui la
finestra è più piccola o più grande di wid , vanno peggio perché
• se la finestra è più piccola parte della banda viene sprecata per l’attesa di arrivo delle conferme;

• se la finestra è più grande il vero handicap viene dalla rete, che non è in grado di accettare per intero
il flusso di dati nelle parti intermedie a velocità minore: in questo caso è infatti necessario accodare
nei router intermedi, cosa che può generare perdite e ritardi.

Figura 2.2: La questione delle capacità e l’adattività del controllo di flusso

Esaminiamo per esempio la figura 2.2; in essa si illustra come il flusso sia in grado di adattarsi alla
capacità e alla banda della rete: se facciamo l’assunzione che vi siano parti di rete ad elevata capacità ed
altre a banda più ristretta (rispettivamente rappresentate da tubi più larghi e più stretti), si nota come il
tempo necessario a trasmettere pacchetti di dimensione fissata sia molto diverso da zona a zona. Il collo
di bottiglia rappresentato dal primo tratto di linea avente banda (stretta) pari B ha l’effetto di rallentare la
trasmissione complessiva di dati: giunti alla parte di rete (veloce) del ricevitore, infatti, i pacchetti sono fra
16 CAPITOLO 2. IL PROTOCOLLO TCP: CONTROLLO DEL FLUSSO

loro temporalmente molto più distanziati rispetto a quanto lo fossero in partenza. Il ritorno, immaginando
che la situazione sia simmetrica rispetto all’andata, non ritarda ulteriormente i pacchetti essendo questi
dei piccoli ACK inviati ad una frequenza ‘sfrondata’ dalla rete d’andata e quindi più che gestibili. Il
protocollo a finestra, come abbiamo detto, permette al trasmettitore di inviare dati solo dal momento
che riceve le necessarie conferme: se esse giungono con la frequenza indicata in figura, la successiva
trasmissione farà sì che il trasmettitore già ‘ab ovo’ invii pacchetti ad una velocità accordata sulla base di
quanto possa sopportare la rete.
Tornando alla questione di partenza, come dimensioniamo CW considerando quanto detto e il fatto
che la banda disponibile B può cambiare durante la connessione? A questo proposito, fatte le ipotesi che
trasmettitore e ricevitore siano correttamente configurati, che non vi siano problemi di SWS (vedi para-
grafo 2.2.1), che i buffer di trasmissione e ricezione siano abbastanza grandi e che AW >> CW (cosicché è
CW a ‘comandare’ nel dimensionamento della finestra), sono definite due fasi che corrispondono a diverse
dinamiche di CW:

• slow start (SS): all’inizio della trasmissione W è3 ≤ 2 e, per ogni ACK ricevuto senza scadenza di
RTO si effettua
W = W+1

L’effetto netto è che, ad ogni tornata, la finestra raddoppia4 (v. figura 2.3). Lo SS termina quando

Figura 2.3: Meccanismo di Slow Start

si verifica congestione (non ritorna un ACK in tempo) oppure quando superiamo la cosiddetta Slow
Start Threshold (SSTHR)5 , che all’apertura della connessione è fissata ad un valore arbitrariamente
alto ma che è anche in grado di cambiare dinamicamente durante la trasmissione dati. In SS si
ipotizza che la situazione di rete, a finestra ancora relativamente piccola, sia abbastanza stazionaria;
l’evoluzione di W, com’è facile intuire, avviene per tempi multipli di RTT (sono gli ACK a dettare il
ritmo). La durata di tale fase dipende chiaramente dalla SSTHR ed è pari a:

TSS = RTT · log2 SSTHR

• congestion avoidance (CA): dopo la crescita esponenziale della fase di SS, con la congestion avoidance
passiamo ad una crescita lineare onde evitare di esagerare e incappare nella perdita di pacchetti. La
finestra w viene incrementata di un MSS per ogni RTT (o, se si preferisce, ogni RTT W aumenta di
un segmento): ad ogni ACK, quindi, si ha

1
W =W+
W

Quindi, ad esempio, se la finestra al ’passo’6 n è pari a 10 segmenti (W (n) = 10), avvenuta la


trasmissione (e se tutto è andato bene) vengono ricevuti 10 ACK e la nuova finestra W (n + 1) diventa7
1
W (n) + 10 · = W (n) + 1.
10
2.4. ALCUNE DEFINIZIONI ED EVOLUZIONE DELLA CW 17

Figura 2.4: Distinzione fra SS e CA

2.4 Alcune definizioni ed evoluzione della CW


Loss Window (LW): quando scade un RTO il trasmettitore ritiene perso un segmento, che quindi de-
v’essere ritrasmesso. Si pone quindi CW ≤ LW (tipicamente LW = 1).

Flightsize: quantità di byte trasmessi ma non confermati (in parole povere è ciò che è in giro per la
rete). Non è necessariamente uguale a W e dipende da dove si e arrivati nella trasmissione di una finestra.

Dopo aver definito queste quantità, chiediamoci: cosa accade se durante la normale evoluzione della
CW, fra slow start e congestion avoidance, scade il Retransmission Time Out8 ?

• se il TCP era in SS: si riparte da capo (W = 1) e si impone che la SSTHR diventi pari al flight-size/2
(o, se quest’ultima quantità è più piccola di due segmenti, a 2)9 ;

• se il TCP era in CA: ripartiamo con la SS e tutto funziona come nel punto precedente.

Si noti che, grazie a questo meccanismo, la rete cerca di adattarsi allo stato della congestione pur
mantenendo un atteggiamento gridy (avido): finché si può, infatti, il TCP cerca di allargare sempre più la
3 Quindi, in byte, w ≤ 2MSS.
4 Quindi è una slow start per modo di dire: in realtà la finestra cresce molto di più qui che in congestion avoidance.
5 Manterremo la convenzione di scrivere ssthr in byte e SSTHR in segmenti.
6 Non possiamo parlare di istanti perché gli ACK e le trasmissioni non avvengono tutte nello stesso momento, quindi approssimer-

emo il cosiddetto passo con un lasso di tempo poco più grande di RTT, quello - cioè - che permette ad un numero di segmenti pari a
quello contenuto nella finestra di essere trasmessi e confermati.
7 In realtà, per essere più precisi, questa relazione dovrebbe essere scritta come approssimazione visto che l’incremento di W
avviene ad ogni ACK e non solo alla fine della tornata (cioè ad ogni ’passo’ e l’altro, v. nota precedente).
ESEMPIO: si ipotizzi W = CW = 4: vengono trasmessi 4 segmenti e, ricevuto il primo ACK risulta,
W = (4 + 1)/4 = 4, 25
Ricevuto il secondo ACK abbiamo
W = (4, 25 + 1)/4, 25 = 4, 49
Ricevuto il quarto ACK, ossia terminato il RTT dell’intera finestra (ovvero il passo di cui parlavamo prima) W = 4, 92 6= 5! Si noti
quindi che non si ha esattamente W = W + 1 dopo la ricezione di tutti gli ACK della finestra. Di conseguenza, la crescita di W
non è esattamente lineare, ma noi per semplicità la considereremo tale.
8 Tipicamente questo evento viene interpretato dal TCP come indice di congestionamento della rete visto che, con buona stima

del RTT, il time out scaduto è praticamente sempre dovuto alla perdita del segmento.
9 Corrispettivo in byte: ssthr = max(W/2, 2MSS ).
18 CAPITOLO 2. IL PROTOCOLLO TCP: CONTROLLO DEL FLUSSO

Figura 2.5: Un esempio d’evoluzione della finestra

sua finestra. Non c’è però pericolo che questo consegni l’intera rete in mano ad un unico host visto che
tutti quanti condividono la stessa politica: infatti il meccanismo delle perdite ha lo scopo di inibire colui
che sovraccarica il mezzo trasmissivo, ridimensionando la sua voracità; piuttosto, il risvolto positivo di
quest’indole è quello di permettere ai colloquianti di occupare l’eventuale banda rilasciata da un calcola-
tore che ha abbandonato la conversazione: in questo modo, la banda è teoricamente sempre sfruttata al
meglio.

2.5 Alcune approssimazioni


Sia TSS la durata della fase di slow-start e TCA quella della fase di congestion avoidance. Se la rete è
abbastanza stabile si ha che:
TSS << TCA

Questo significa che passiamo molto più tempo in CA piuttosto che in SS e questo è un bene visto
che, in ultima analisi, la quantità di dati trasmessi è pari all’integrale della curva presente nel grafico
finestra/tempo e, chiaramente, l’area che si trova sotto la curva che evolve in CA è maggiore di quella
sotto la curva in zona di SS. Se l’ipotesi TSS << TCA è vera, allora possiamo trascurare la fase di SS e
immaginare un andamento perennemente in CA, come in figura 2.6.
L’algoritmo di Congestion Avoidance viene anche detto di incremento additivo e decremento moltiplica-
tivo: se r è la quantità di dati inviata dal trasmettitore

• additive-increase: la finestra cresce in maniera additiva. Al passo i-esimo si ha:

r ( t i +1 ) = r ( t i ) + c con c << rmax

• multiplicative-decrease: la finestra decresce in maniera moltiplicativa. Se si ha una situazione di


congestione al passo i-esimo si ha:

r ( t i +1 ) = a · r ( t i ) con a < 1
2.5. ALCUNE APPROSSIMAZIONI 19

Figura 2.6: Effetto dell’approssimazione TSS << TCA

Perché tutte queste definizioni? Il punto cui vogliamo arrivare è dimostrare che il TCP permette un’e-
qua distribuzione della banda disponibile: questo significa che se un certo numero di colloquianti (noi per
semplicità ne considereremo due) condividono una certa banda, a regime finiranno per avere più o meno
tutti la stessa porzione di essa.

2.5.1 Un esempio

Figura 2.7: Condivisione della risorsa

Si faccia riferimento alla figura 2.7: abbiamo due connessioni che si ritrovano a condividere la stessa
banda. Siccome entrambi i calcolatori (r1 e r2 sul grafico: gli assi rappresentano la banda destinata
a ciascuno di essi) adottano il tanto decantato approccio gridy, tenteranno di accaparrarsi quante più
risorse possibili. Così facendo arriverà inevitabilmente il momento in cui si dovrà sbattere il muso contro
l’impossibilità di congestionare troppo la rete: prendiamo per esempio r2 che, per ipotesi, parte con un
maggior sfruttamento della banda. Dopo un appagante incremento additivo, la freccia verde si scontra
contro il limite (linea scura) e si ha in decremento moltiplicativo (freccia rossa). Il giro successivo, r2 non
potrà occupare così tanta banda come l’ultima volta perché, nel frattempo r1 gli avrà rosicchiato un po’ di
risorse da sotto i piedi. Nonostante questo, r2 ha un incremento additivo che lo riporta (quasi) ai livelli
di un tempo; anche stavolta, tuttavia, scatta un RTO a causa della troppa avidità del nostro host e così
si ha un’ulteriore freccia rossa corrispondente a un decremento moltiplicativo. Questa tendenza continua
20 CAPITOLO 2. IL PROTOCOLLO TCP: CONTROLLO DEL FLUSSO

fino a quando la freccia rossa e la freccia verde hanno la stessa pendenza, pari tra l’altro alla bisettrice
del nostro quadrante: giunti lì, a meno di inconvenienti particolari, i due host avranno decrementi ed
incrementi simili e ciò porterà ad avere, a regime, una sostanziale equipartizione della banda (il punto di
intersezione fra la bisettrice e la retta ad essa perpendicolare è quello di massimo equilibrio fra le risorse
destinate ai due calcolatori). Si noti che tutto questo è reso possibile dall’atteggiamento gridy, avido e
assetato di banda, imposto dal TCP: se così non fosse non riusciremmo ad avere uno sfruttamento così
intenso e sistematico della capacità del nostro canale. Inoltre, se uno dei due host dovesse andarsene,
quello rimanente non approfitterebbe subito della banda liberatasi e l’efficienza sarebbe piuttosto scarsa.

2.6 Altri aspetti del protocollo: algoritmi migliorativi


Una cosa che è importante sottolineare è che la politica dei delayed ACK (non inviare gli ACK sem-
pre, ma ogni K > 1 corrette ricezioni) può portare a degli squilibri. Se prendiamo in considerazione
l’esempio nel paragrafo 2.5.1 e facciamo l’ipotesi che uno dei due colloquianti invii un ACK ogni quattro
segmenti invece che ad ogni singolo datagramma, allora quest’ultimo calcolatore sarà indiscutibilmente
danneggiato perché, al contrario dell’altro contendente, non riuscirà a raggranellare banda al suo stesso
ritmo.
Preme inoltre sottolineare che l’incremento di CW è funzione del round-trip time; due connessioni che
sperimentano diversi RTT aumentano in modo diverso le proprie finestre e si tende a favorire connessioni
con RTT brevi su connessioni con RTT lunghi.
Quando poi un segmento viene perso, il ricevitore riceve uno o più segmenti fuori sequenza: se ciò
avviene, il protocollo TCP (quello nudo e crudo, senza gli algoritmi che vedremo fra poco) è costretto ad
inviare un ACK duplicato10 per ogni segmento fuori ordine. La generazione di ACK duplicati dovuti alla
perdita di un segmento è un evento che può essere utilizzato come indicazione di congestione unitamente
al time-out. Sono quindi stati proposti ulteriori algoritmi per sfruttare al meglio questa situazione: di
questi noi tratteremo il fast recovery (paragrafo 2.6.1) e il fast retransmit (paragrafo 2.6.2).

2.6.1 Fast recovery


Questo algoritmo entra in funzione quando avviene il caso di triple duplicate ACK (tre ACK duplicati):
se il trasmettitore riceve infatti 4 ACK con uguale acknowledge number allora si ritrasmette il segmento
avente come numero di sequenza quello indicato dall’ackN duplicato. E poi che si fa? Si potrebbe
ripartire dall’inizio della slow start, ma quella di far ricrollare la finestra allo stadio embrionale non è una
scelta furbissima: il fatto che il ricevitore ci stia rispondendo, infatti, è sintomo che i pacchetti stanno
effettivamente giungendo a destinazione e che quindi vi è abbastanza reattività da parte della rete (e non
vi è perciò una situazione esageratamente congestionata). Inoltre, potrà pure capitare che ogni tanto si
perde qualche pacchetto!11 Considerando quindi il triplo ACK duplicato come evento ’meno grave’ di un
RTO effettivamente scaduto, si preferisce agire ritrasmettendo il solo segmento mancante e continuando
la fase di congestion avoidance.
Ecco i passi dell’algoritmo (per visionare alcuni esempi si faccia riferimento alle figure 2.8 e 2.9:

• si riduce la soglia di CW a SSTHR = max( Flightsize/2, 2) o, se si preferisce questa quantità in byte,


a ssthr = max( Flightsize/2, 2MSS): questo passo serve per riadattarci alle condizioni di carico della
rete;

• si gonfia (provvisoriamente) la finestra W (window inflation) aumentandone istantaneamente la di-


mensione di tre pacchetti: W = SSTHR + 3 (o, come al solito, w = ssthr + 3MSS in byte). Così
facendo si tiene conto del fatto che almeno 3 segmenti successivi al mancante sono stati ricevuti in
quando sono partiti gli ACK duplicati;

• si continua la trasmissione e, se la dimensione di W lo permette, si trasmettono ulteriori segmenti;

• ad ogni ulteriore ACK duplicato ricevuto si pone W = W + 1;


10 Che si riferisce all’ultimo segmento ricevuto correttamente.
11 Suvvia!
2.6. ALTRI ASPETTI DEL PROTOCOLLO: ALGORITMI MIGLIORATIVI 21

Figura 2.8: L’algoritmo di fast recovery

• quando arriva l’ACK per il pacchetto perduto finisce la fase di FR e si riparte con congestion avoidance
ponendo W = SSTHR (la finestra viene sgonfiata).

Figura 2.9: L’algoritmo di fast recovery (2)

Il TCP standard, messo di fronte a un’eventualità come quella illustrata nell’esempio in figura 2.8,
22 CAPITOLO 2. IL PROTOCOLLO TCP: CONTROLLO DEL FLUSSO

sarebbe impazzito, in quanto avremmo dovuto per forza attendere lo scadere dei time out prima di
ripartire. Anche solo due pacchetti persi in breve tempo avrebbero infatti creato una situazione di stallo e
avrebbero fatto ripartire il tutto dalla slow start, con un conseguente crollo della finestra. Non è però tutto
oro quel che luccica: a volte, infatti, il fast recovery può addirittura essere dannoso e peggiorativo!

2.6.2 Fast retransmit


Il fast retransmit (una specie di fast recovery semplificato12 ), consiste nel dimezzare la finestra e spedire
immediatamente, senza aspettare l’RTO come invece accadrebbe nel TCP classico, il pacchetto del quale
si è ricevuta la richiesta duplicata (tripla, come da programma).
Consideriamo infatti la seguente casistica:

• 12 segmenti ricevuti, riconosciuti e confermati;

• segmenti 13 e 16 perduti.

In figura 2.10 si mostra come il TCP standard (SS+CA) e il TCP ’Tahoe’13 (SS+CA+Fast Retransmit)
avrebbero agito e si nota chiaramente come quest’ultimo sia più efficiente.

Figura 2.10: Il TCP classico e il Tahoe (cioè TCP + Fast Rec.) a confronto
12 O magari è il fast recovery ad essere una versione più evoluta del fast retransmit: la sostanza però è quella. Mediamente il fast

recovery funziona meglio, ma in alcuni casi potrebbe non essere così, quindi ha senso vedere questi due algoritmi separatamente.
13 Da Wikipedia:

TCP Tahoe prevede che ogni qual volta si verichi un evento perdita di qualsiasi tipo, la nestra di congestione venga dimezzata
e il nuovo valore memorizzato in una variabile soglia. Fatto questo la trasmissione dei dati ricomincia impostando il valore iniziale
della nestra di congestione corrente pari a MSS (massima dimensione di un segmento TCP). Si ha quindi una 'ripartenza lenta', la
crescita avverrà lentamente ma in maniera esponenziale no a raggiungere il valore di soglia prima determinato [è la SS]. Oltre questo
valore la crescita avviene linearmente [CA] no a quando non si verica nuovamente un evento perdita e l'algoritmo viene rieseguito.
La crescita esponenziale no al livello di soglia avviene poiché si ritiene che all'inizio di ogni trasferimento il canale trasmissivo sia più
libero, e quindi si cerca di inviare all'inizio i pacchetti più grossi. Una volta raggiunto il livello di soglia, la crescita avviene lentamente
per cercare di raggiungere il livello di congestione il più lentamente possibile.
2.6. ALTRI ASPETTI DEL PROTOCOLLO: ALGORITMI MIGLIORATIVI 23

Qual è il problema del Tahoe? Ebbene, il vantaggio ottenuto è molto piccolo (se non nullo) perché il
dimezzamento della finestra blocca la trasmissione a causa delle perdite multiple.

2.6.3 Reno e New Reno


Nel caso illustrato nel paragrafo 2.6.1 il cosiddetto TCP ’Reno’14 (SS+CA+Fast Recovery) non sarebbe
andato molto meglio (v. figura 2.11). Il ’New Reno’15 , invece, avrebbe avuto delle performance migliori (si
faccia nuovamente riferimento alla figura 2.11).

Figura 2.11: I protocolli TCP Reno e TCP New Reno a confronto

Come si osserva facilmente, il TCP Reno si infogna subito (segmenti pendenti 5, W = 5 → non si può
trasmettere altro finché non riceviamo ACK 13: dopodiché si esce dal fast recovery e si riparte con finestra
2: il trasmettitore è nuovamente bloccato ed è costretto ad attendere l’RTO di 16, allo scadere del quale si
ritrasmette con finestra a 1. . . Oltre al danno pure la beffa!): terminare il fast recovery troppo presto (cioè
ad ackN=15) è infatti prematuro.
14 Ancora una volta Wikipedia ci aiuta con una sua spiegazione:
TCP Reno [...] in caso di perdita dovuta al timeout del timer, applica l'algoritmo di Tahoe, poiché si assume che la rete sia
talmente congestionata da non essere in grado di far passare nessun altro pacchetto e che quindi sia meglio far ripartire la trasmissione
impostando la nestra corrente al valore minimo di 1 MSS. Quando invece l'evento perdita è generato dalla ricezione di 3 ACK
duplicati, il TCP Reno assume che la rete sia ancora in grado di trasferire qualcosa. Il valore soglia viene impostato alla metà del
valore della nestra di congestione al momento della ricezione di tre ACK duplicati e la trasmissione riparte impostando il valore
di nestra corrente pari al valore di soglia e proseguendo nell'invio incrementando di MSS, ad ogni RTT, il valore della nestra di
congestione.
15 La solita Wikipedia:
Il TCP Reno risolve in parte il problema di perdite non dovute a congestione solo quando le perdite non sono fortemente correlate
tra loro, cioè quando si perde al massimo un pacchetto all'interno di ogni nestra. Questo comportamento è problematico nelle
situazioni in cui si perdono interi burst di pacchetti (situazione frequente ad esempio nei collegamenti wireless). TCP New Reno
cerca di aggirare il problema basandosi sul sistema degli ACK parziali. Vengono considerati ACK parziali gli ACK che riscontrano
pacchetti intermedi, e non gli ultimi pacchetti che necessiterebbero riscontro, dopo che è stata già iniziata la fase di Fast Retransmit
in seguito all'arrivo di tre ACK duplicati. Quando uno di questi ACK si presenta durante una fase di Fast Retransmit (cioè in seguito
alla ricezione di 3 ACK duplicati), TCP New Reno si mantiene in Fast Retransmit continuando a inviare i pacchetti via via richiesti
nché non viene riscontrato l'ultimo pacchetto inviato.
24 CAPITOLO 2. IL PROTOCOLLO TCP: CONTROLLO DEL FLUSSO

Il New Reno fa tesoro di questa esperienza e reagisce meglio, mantenendo la finestra gonfiata per un
po’ più di tempo, quel che basta per scavalcare i pacchetti corretti successivi a quello sbagliato e poter
riprendere la numerazione in santa pace, senza aspettare lo scadere degli RTO. La fase di recupero inizia
all’istante (che chiameremo T0 ) di ricezione del quarto duplicato: giunti lì memorizziamo infatti seqN(T0 )
= 17. Questo numero indica infatti il seqN dell’ultimo pacchetto che si presume sia stato correttamente
ricevuto dal ricevitore: dopo la ripetizione dei 3 pacchetti aventi seqN = 13 esso rappresenterà quindi la
prima informazione ’buona’ disponibile dopo i 3 duplicati. Il numero memorizzato è quindi utile perché,
proprio per i motivi poco fa indicati, l’algoritmo prevede che si esca dalla fase di Fast Recovery quando si
riceve ackN > seqN(T0 ). Se dopo la spedizione del segmento perduto (il 13simo) tutta la finestra è stata
ricevuta correttamente allora arriverà ackN = 18 (si esce dal Fast Recovery) mentre, se sono stati perduti
altri segmenti della finestra, ackN < 18 (ACK parziale, che re-inizializza RTO).
Capitolo 3

Modelli analitici per le prestazioni del


TCP

3.1 Ricerca di modelli matematici


Le prestazioni del protocollo TCP vengono influenzate fondamentalmente dalla dinamica della fines-
tra di trasmissione W (che viene regolata dal controllo di congestione e dal protocollo ARQ) nonché dai
processi di ritardo e perdita di segmenti in rete (vedi capitolo ??). Un modello analitico del TPC deve de-
scrivere questi processi fondamentali e, nello stesso tempo, riuscire a valutare le prestazioni del protocollo.
Sembra una cosa banale, ma in realtà esistono diverse questioni delicate da affrontare, in quanto:

• gli eventi consistenti nella perdita di pacchetti sono aleatori;

• la rete ha una natura dinamica ed è impossibile racchiudere in un solo modello tutte le possibili
eventualità che si potrebbero presentare;

• è difficile tenere conto di tutta l’infrastruttura che si trova tra ricevitore e trasmettitore: tra i due
colloquianti, infatti, si trovano vari router - non necessariamente uguali - con code di lunghezza
diversa e prestazioni differenti;

• se siamo in congestion avoidance l’andamento della finestra è approssimativamente lineare e le cose


vanno bene; se vogliamo considerare anche la slow start nonché le dinamiche dei protocolli più
evoluti (Tahoe, Reno, New Reno, etc. . . ), allora il problema si complica notevolmente;

• il RTT non è in generale un parametro costante;

• non valutiamo la possibilità che la banda venga occupata, durante il periodo che ci interessa, da altri
calcolatori;

• etc. . .

Per questi ed altri motivi, di seguito studieremo alcune situazioni notevoli adeguatamente semplificate.

3.2 Throughput e goodput


Il throughput di una connessione TCP è la quantità totale di informazioni trasmesse nell’unità di
tempo.
Il goodput, invece, è la quantità di informazioni trasmesse con successo nell’unità di tempo (senza
contare i segmenti trasmessi con errore o duplicati).
Intuitivamente, si ha che:
throughput ≥ goodput

25
26 CAPITOLO 3. MODELLI ANALITICI PER LE PRESTAZIONI DEL TCP

Nei modelli TCP più comuni il tempo è logicamente1 diviso in unità di dimensione RTT: supporremo che
in RTT venga trasmessa un’intera finestra e che, al termine di tale periodo, giungano tutte le conferme di
ricezione. Fatte queste ipotesi il throughput è semplicemente il numero di segmenti trasmessi per RTT:

w(t) W (t) · MSS


S(t) = =
RTT RTT
Di seguito supporremo che il trasmettitore abbia infiniti dati da trasmettere (e che spedisca sempre seg-
menti di dimensioni pari a MSS), che i buffer di trasmissione e ricezione non limitino il comportamento
del TCP (lo stato delle code nei router rimane approssimativamente costante e non si modifica in modo
significativo durante il periodo d’analisi) e - infine - che si lavori perennemente in congestion avoidance.

3.3 Modello periodico


Si tratta del modello più semplice: esso assume che

• si lavori in una situazione di equilibrio, con il TCP in congestion avoidance: questo comporta inoltre
che, ad ogni perdita, la finestra si dimezzi (e non riparta da 1 o 2);

• si riceva un ACK per ogni segmento correttamente ricevuto;

• gli eventi di perdita siano periodici, in percentuale di p.

Fatte queste ipotesi, la finestra ha in funzione del tempo un andamento periodico a dente di sega (v.
figura 3.1.

Figura 3.1: Modello periodico

Supponendo che, ad ogni finestra (batch) vengano trasmessi W segmenti, lo stato di congestion avoidance
fa sì che, al termine di essa, si riceva l’ACK che fa scattare W = W + 1. Se non si riceve l’ACK, invece, la
finestra viene dimezzata per effetto della congestione (vedi figura 3.2).

Figura 3.2: Modello periodico (2)


1 Nel senso che a noi fa comodo pensare che le cose vadano così: in realtà i pacchetti non arrivano tutti contemporaneamente e,

di conseguenza, la finestra si aggiorna non soltanto ad ogni RTT. Anche questa, pertanto, è un’approssimazione.
3.3. MODELLO PERIODICO 27

Sia ora N il numero di segmenti trasmessi in T (periodo che intercorre tra una perdita e l’altra). Se
assumiamo che la perdita avvenga periodicamente, allora possiamo dire che, se ad esempio la perdita è
di 1 segmento su 100, all’interno di T avremo spedito 100 segmenti:

1
N=
p

Possiamo però dare un’espressione di N anche in funzione della finestra2 :


  
W W
W −1 − 1
2
W W2 2 2 W2 W2 3W 2
N= ∑ +i = + ≈ + =
i =0
2 4 | 2
{z } 4 8 8
serie del ’piccolo Gauss’

Per capire a fondo questa espressione si tenga presente che la sommatoria ha quegli estremi visto che la
finestra, per ogni dente di sega, varia da W/2 a W (per un delta complessivo che va da 0 a W/2) e che
il +i indica la crescita pari ad 1 della finestra per ogni RTT. Uguagliando le due espressioni si ottiene
facilmente: s
8
W=
3p
Il throughput si calcola come rapporto fra:

• numero di pacchetti trasmessi = 1/p;


W
• tempo totale di trasmissione = RTT.
2
Ed è quindi pari a: s
   r
1 p 2 p 1 2 p 3p 1 3
S ( p) = = = =
W RTT W RTT 8 RTT 2p
RTT
2

3.3.1 ACK ritardati


Facciamo ora l’ipotesi aggiuntiva che il ricevitore spedisca un ACK ogni b segmenti e non ogni seg-
mento. In tal caso, se trasmettiamo una finestra W riceveremo non più W ACK, ma W/b ACK: questo
farà sì che

• W = W + 1/b;

• W = W + 1 solo dopo b finestre trasmesse.

Il periodo T che intercorre tra una perdita e l’altra sarà quindi pari a:

Wb
T= RTT
2
Si noti che questo tempo è b volte quello esaminato nel caso di ACK non ritardati. Possiamo quindi fare
calcoli analoghi e quelli già visti nel paragrafo 3.3: il parametro N (segmenti spediti all’interno del dente
di sega) è pari a
  
bW bW
W −1 − 1
2
W i bW 2 2 2 bW 2 bW 2 3bW 2
N= ∑ + = + ≈ + =
i =0
2 b 4 | 2
{z } 4 8 8
Ancora il piccolo Gauss

2 Con la ’serie del piccolo Gauss’ (cit. Seccia) intendiamo:


k
k ( k + 1)
∑= 2
i =0
28 CAPITOLO 3. MODELLI ANALITICI PER LE PRESTAZIONI DEL TCP

Quindi, uguagliando nuovamente questa relazione con


1
N=
p
si ha: s
8
W=
3bp
E quindi il throughput sarà:
   r s
1 p 2 p 1 2 p 3pb 1 3
S ( p) = = = =
W RTT bW b · RTT 8 RTT 2pb
RTT b
2

3.4 Perdite aleatorie

Figura 3.3: Andamento della finestra con perdite aleatorie

Se complichiamo leggermente il modello, rimuovendo l’ipotesi che le perdite siano periodiche e ag-
giungendo quelle che siano aleatorie, allora già le cose si fanno più complicate! Supponiamo che la
trasmissione avvenga ancora a batch (uno per RTT e di dimensioni pari alla finestra W) e che gli ACK
siano ritardati (uno ogni b pacchetti). Sia inoltre la probabilità di perdita indipendente sia da segmento a
segmento che da batch a batch. In questo caso, com’è prevedibile, l’andamento a dente di sega non sussiste
più (v. figura 3.3).
Facciamo inoltre l’ipotesi che siano due gli eventi a determinare la contrazione di CW (t):
• il triple duplicate ACK (TD): in tal caso il protocollo reagisce con un fast retransmit (trascureremo il fast
recovery);
• la scadenza di un timeout (TO): in questo caso dimezziamo la finestra (senza ripartire dalla slow start).
Per ora immagineremo che AW sia abbastanza elevata da essere CW a spuntarla sempre sul controllo
della finestra (poi rimuoveremo questa ipotesi).

3.4.1 Modello TD
Sia Yi la variabile aleatoria che indica quanti pacchetti sono stati inviati all’interno di un periodo in
cui non vi sono stati errori3 : anche quest’ultimo lasso di tempo è una variabile aleatoria che indicheremo
con Ai e che, chiaramente, sarà pari al numero di RTT che intercorrono tra l’inizio del ’dente’ del grafico
e l’istante in cui si verifica la perdita (vedi figura 3.4). Sia poi αi il numero del pacchetto4 che provoca la
perdita e p la probabilità che avvenga una perdita; infine, sia Wi il valore della finestra nel momento in
cui è avvenuta la perdita e β i la metà di Wi 5 . Si noti che le variabili Yi , Ai , Wi αi e β i sono tutte aleatorie e
tutte riferite all’analisi del dente di sega i.
La variabile aleatoria Yi (numero dell’ultimo pacchetto spedito nella tornata6 i) sarà chiaramente pari
3 Cioè all’interno del dente di sega.
4 Un numero relativo al dente di sega i, non il suo numero assoluto!
5 Abbiamo fatto l’ipotesi di mantenerci sempre in congestion avoidance e di ignorare lo SS.
6 La tornata comprende anche i β pacchetti spediti nel mentre la finestra si dimezzava.
3.4. PERDITE ALEATORIE 29

Figura 3.4: Le variabili Yi e Ai

a
Yi = αi + Wi − 1
cioè al numero relativo numero del primo pacchetto errato più il valore che la finestra aveva quand’è
avvenuto l’errore, meno 1 (che ci fa beccare l’ultimo bit giusto). Applicando l’operatore di valor medio,
che è lineare, si ha:
E[Yi ] = E[αi ] + E[Wi ] − 1
La probabilità che αi sia pari a un certo numero k è modellabile ipotizzando che i k − 1 pacchetti precedenti
siano stati correttamente ricevuti (probabilità 1 − p) mentre il k-simo sia stato ’scagliato’:
Pr{ a = k } = (1 − p)k−1 p
Il valore medio di α è chiaramente legato alla probabilità d’errore p dalla seguente relazione (che ci
riporta alla memoria il caso periodico, v. par. 3.3):
E[α] = 1/p
Sostituendo otteniamo quindi:
1 1− p
E[Yi ] = E[αi ] + E[Wi ] − 1 = + E[Wi ] − 1 = E[Wi ] +
p p
Infine, il periodo di trasmissione senza errori, che come abbiamo detto è pari al numero di RTT che
intercorrono tra l’inizio del ’dente’ del grafico e l’istante in cui si verifica la perdita, sarà esprimibile nel
seguente modo:
Xi + 1
Ai = ∑ RTT
j =1

Se supponiamo che RTT sia costante (rete abbastanza stabile), il suo valor medio è legato a quello di Xi
dalla formula:
E[ A] = ( E[ X ] + 1) · RTT
Ora ci serve un legame fra Y (numero di pacchetti correttamente spediti), X (numero di RTT effettuati
in un dente di sega) e W (valore della finestra prima del suo crollo): per trovarlo attingiamo dal paragrafo
3.3.1, visto che - per ipotesi - spediamo b finestre7 prima di ricevere un’ACK in grado di incrementare la
nostra W (t) di 1. Intuitivamente, infatti, il massimo valore raggiunto dalla finestra nella tornata i sarà pari
al numero di RTT totali diviso per b (X/b è quindi il numero intero che indica di quanto è aumentata la
finestra, ovvero il numero degli ACK che sono riusciti ad incrementare la finestra8 ) sommato al valore di
partenza (che coincide con il valore finale della tornata i − 1, dimezzato):
Wi−1 X Xi W
Wi = + i → = Wi − i−1
2 b b 2
7 O, se si preferisce, aspettiamo b RTT prima di osservare un incremento della finestra.
8 O, se si preferisce, il numero di volte in cui la finestra è aumentata di 1.
30 CAPITOLO 3. MODELLI ANALITICI PER LE PRESTAZIONI DEL TCP

Figura 3.5: Le variabili aleatorie in gioco nel modello TD

Il numero di segmenti Yi trasmessi nella tornata i è invece calcolabile nel seguente modo: ogni b
finestre, abbiamo detto, incrementiamo W (t) di 1; questo significa che, ad ogni incremento, avremo spedito
un numero di segmenti pari al numero di RTT necessari a far incrementare la finestra (= b) moltiplicato
W
per il valore che la finestra ha avuto per gli ultimi b RTT, ovvero i−1 + k, dove k è un contatore che ci
2
dice quanti incrementi di finestra sono avvenuti fin’ora. Se ora mettiamo il tutto in sommatoria e facciamo
X
andare k da 0 fino a i − 1 (il −1 serve a ignorare l’ultimo RTT, all’interno del quale sono stati inviati solo
b
β i pacchetti, che sommiamo separatamente) otteniamo:

Xi Xi
−1  −1
b W

Xi Wi−1 b
Yi = ∑ i −1
+ k + βi = b +b ∑ k + βi =
j =0
2 |b {z2 } j =0
portiamo fuori da sommat.
  
Xi Xi
−1    
Xi b b b X b X X X
= Wi−1 + b + βi = i Wi−1 + i − 1 + β i = i Wi−1 + i − 1 + β i
b 2 | 2
{z } b 2 b 2 b
Piccolo Gauss!

Xi
Ricordando ora l’espressione che avevamo per , otteniamo l’espressione finale di Yi :
b
     
X X Xi b W
Yi = i Wi−1 + i − 1 + β i = −1 Wi + i−1 − 1 + β i
2 b b 2 2
Giunti fin qui siamo ben felici dei nostri risultati: mostriamo però che, in termini medi, tutto va come
nel caso di modello periodico9 (par. 3.3). Applichiamo l’operatore di valor medio ad un espressione
leggermente approssimata della Yi per ottenere:
 
E [ Xi ] E[Wi−1 ]
E[Yi ] = E[Wi ] + − 1 + E[ β i ]
2 2
Si noti che quanto abbiamo fatto è stato reso possibile dall’indipendenza delle variabili aleatorie Xi e Wi .
Infine tenendo conto che, come abbiamo già sottolineato nel corso di questa trattazione

E [W ]
E[ β] =
2
9 Avevamo già avuto un assaggio di quanto ora detto quando dicemmo che il valore medio di α è legato alla probabilità d’errore

p dalla seguente relazione (assolutamente coincidente a quella citata nel modello periodico):
E[α] = 1/p
3.4. PERDITE ALEATORIE 31

e
1− p
E [Y ] = E [W ] +
p
otteniamo (eliminando tutti i pedici che sono inutili in questa trattazione ’media’):
 
E[ X ] E [W ]
E [Y ] = E [W ] + − 1 + E[ β]
2 2
1− p
 
E[ X ] E [W ] E [W ]
E [W ] + = E [W ] + −1 +
p 2 2 2
1− p E [ X ] E [W ] E [ X ] E [W ] E[ X ] E [W ]
E [W ] + = + − +
p 2 4 2 2
E [W ] E [ X ] E [W ] E[ X ] 1 − p
=3 − −
2 4 2 p

Ora sostituiamo tenendo conto che10


2E [ X ] b
E [W ] = ⇒ E [X] = E [W ]
b 2
Ci tocca fare qualche calcoletto:

E [W ] E [ X ] E [W ] E[ X ] 1 − p
=3 − −
2 4 2 p
   
b b
E [W ] E [W ] E [W ]
E [W ] 2 2 1− p
=3 − −
2 4 2 p
1− p
 
3b 2 b+2
E [W ] + − E [W ] − =0
8 4 p
4 (1 − p )
 
1 2 b+2
E [W ] + − E [W ] − =0
2 3b 3pb
s s
b+2 2 1 4 (1 − p ) b + 2 2 8 (1 − p )
 
b+2 b+2
E [W ] = + +4· = + +
3b 3b 2 3pb 3b 3b 3pb
1
Se supponiamo che p << 1 (cosa largamente auspicabile) allora 1 − p → 1 e p >> 1, quindi riotteniamo:
s
8
E [W ] ≈
3bp

Anche se consideriamo il throughput, mediamente le cose tornano ad andare come nel caso periodico:
infatti
E [Y ] E [Y ]
S( p) = =
E[ A] ( E[ X ] + 1) · RTT
Ricordiamo però che: s 2
b b+2 b+2 8b (1 − p)
E [ X ] = E [W ] = + +
2 6 6 3p
10 Cioè il valor medio della finestra W, alla fine del dente di sega, è pari al prodotto fra il numero di RTT all’interno del dente

fratto gli RTT necessari ad incrementare di 1 la finestra (= b) il tutto moltiplicato per due. Questo deriva dalla rimozione di pedici
(dovuta all’introduzione dell’operatore E[· · · ]) nella relazione:
Wi−1 X
Wi = + i
2 b
Che diventa quindi:
E [W ] E[ X ]
E [W ] = +
2 b
E[ X ]
E [W ] = 2
b
32 CAPITOLO 3. MODELLI ANALITICI PER LE PRESTAZIONI DEL TCP

E che
1− p
E [Y ] = + E [W ]
p

Quindi, sostituendo e approssimando:


s
− b + 2 2 8 (1 − p )

1− p 1 p b + 2
+ E [W ] + + + s
p p 3b 3b 3bp p << 1 1 3
S ( p) = =   −−−−→
RTT ( E[ X ] + 1) RTT 2bp
s 2
b+2 b+2 8b (1 − p)
RTT  + + + 1
6 6 3p

3.4.2 Modello TD+TO


Se ora consideriamo anche la possibile scadenza dei time-out, l’andamento della finestra W (t) si fa
ancora più diversificato nel tempo (v. figura 3.6).

Figura 3.6: Modello TD+TO

In questo caso il throughput è pari a:

1
S ( p) ≈ r r !
2bp 3bp
RTT + T0 min 1, 3 p (1 + 32p2 )
3 8

3.4.3 Modello TD+TO+AW

Figura 3.7: Modello TD+TO+AW


3.5. MODELLI A CONFRONTO 33

Se consideriamo anche l’eventualità che AW possa limitare W (v. figura 3.7) allora il throughput diventa
pari a:  
 
 Wmax 1 
S ( p) ≈ min 
 RTT , r r ! 
2bp 3bp

RTT + T0 min 1, 3 p (1 + 32p2 )
 
3 8
Qual è il senso di questa formula approssimata? Essa in pratica sceglie fra due alternative:

• se AW è abbastanza grande allora possiamo tenere buona la stima del modello TD+TO;

• se AW è molto restrittiva, allora saranno molte le parti del grafico in cui tale limite ’taglia’ le punte
Wmax
dei denti di sega, creando delle aree rettangolari (approssimabili da ).
RTT
Quanto detto è maggiormente comprensibile visionando la figura 3.8.

Figura 3.8: L’approssimazione introdotta dalla formula di AW

3.5 Modelli a confronto


Nelle figure 3.9 - 3.12 vengono messi a confronto i vari modelli (figura 3.9) e vengono esaminati gli
effetti della variazione dei parametri p, RTO, RTT, AW sul modello completo (TD+TO+AW) (figure 3.10,
3.11, 3.12).
34 CAPITOLO 3. MODELLI ANALITICI PER LE PRESTAZIONI DEL TCP

Figura 3.9: Modelli a confronto

Figura 3.10: Influenza dell’RTT sul modello


3.5. MODELLI A CONFRONTO 35

Figura 3.11: Influenza di AW sul modello

Figura 3.12: Influenza di RTO sul modello


36 CAPITOLO 3. MODELLI ANALITICI PER LE PRESTAZIONI DEL TCP

3.6 Latenza
Si definisce latenza L il tempo che intercorre fra l’istante ti in cui il client inizia una connessione TCP e
l’istante t f in cui i dati richiesti sono completamente ricevuti.

L = t f − ti

Per il calcolo di tale parametro faremo qualche ipotesi semplificativa:

• W limitata solamente da CW del trasmettitore (AW sufficientemente grande);

• assenza di ritrasmissioni;

• overhead dovuto alle intestazioni trascurabile;

• file costituito da un numero intero di MSS;

• i segmenti che non trasportano dati, ma solo informazioni di servizio, hanno tempi di trasmissione
trascurabili.

Indicheremo con:

• P (bit): dimensione del file di dati (ad es. pagina web) da trasferire;

• MSS (bit): il maximum segment size;

• C (bit/s): velocita del canale dal server al client.

Figura 3.13: I passi imprescindibili per effettuare un trasferimento dati

Nel caso in cui non ci sia limitazione al flusso dati dovuta al protocollo a finestra occorre un RTT per
iniziare la connessione TCP (protocollo TWH Three Way Handshake); trascorso un RTT viene inviata la
richiesta dell’oggetto e, dopo 2 RTT, il client comincia a ricevere i dati richiesti. Instaurato il trasferimento
dei dati, essi vengono ricevuti per un periodo pari a P/C. I passi definiti fin’ora sono obbligatori e
imprescindibili (v. figura 3.13), quindi il limite inferiore (lower bound) per la latenza risulta essere:

P
Lmin = 2RTT +
C

In generale L > Lmin a causa delle perdite e delle non-idealità della rete.
3.6. LATENZA 37

3.6.1 Finestra a dimensione fissa


Facciamo ora l’ipotesi che la finestra abbia dimensione fissa pari a W. Quando il server riceve la
richiesta del client parte spedendogli W segmenti. Successivamente invia un segmento per ogni riscontro
ricevuto; occorre però considerare due casi:
W · MSS MSS
• ≥ RTT + → il server riceve il primo riscontro prima di aver terminato la trasmissione
C C
W · MSS MSS
della finestra: è infatti il tempo necessario a spedire un’intera finestra, mentre RTT +
C C
è il tempo che ci mette un segmento ad partire e a tornare (sottoforma di conferma);
W · MSS MSS
• < RTT + → il server termina la trasmissione della finestra prima di aver ricevuto il
C C
riscontro.

W · MSS MSS
Caso ≥ RTT +
C C
Instaurata la connessione i segmenti continuano ad essere trasmessi a velocità C fino a che l’oggetto
non è stato completamente inviato. In questo caso la latenza è uguale a quella minima:
P
L1 = Lmin = 2RTT +
C

Figura 3.14: Esempio con W = 6

In figura 3.14 si può visionare un esempio di quanto detto.

W · MSS MSS
Caso < RTT +
C C
Inviata una finestra il server deve arrestarsi per aspettare il riscontro. Una volta arrivati i riscontri
viene trasmessa una nuova finestra11 . Il numero di finestre per trasmettere l’oggetto 12 è pari a:
P
K=
W · MSS
Il server è in attesa nell’intervallo tra la trasmissione di due finestre consecutive e quindi per K − 1 volte.
Facciamo il calcolo della latenza:
P
L2 = 2RTT + + (K − 1) TA
C
P
2RTT + è il tempo che avremmo speso anche nell’altro caso; TA è il tempo ’perso’ per ogni segmento e
C
K − 1 è il numero di segmenti per cui si perde tempo.
11 Il server si può quindi trovare o nello stato di trasmissione o nello stato di attesa di riscontro.
12 Se non è intero si arrotonda all’intero più vicino
38 CAPITOLO 3. MODELLI ANALITICI PER LE PRESTAZIONI DEL TCP

Figura 3.15: Schema esplicativo della formula di L2

La seguente espressione è equivalente a quella scritta poco sopra (si osservi la figura 3.15 per capire
come ottenerla13 :
W · MSS
 
S
L2 = 2RTT + (K − 1) + RTT + =
C C
W · MSS W · MSS W · MSS W · MSS
 
= 2RTT + (K − 1) + RTT + − +
C C C C
(W − 1) · MSS
 
P
= 2RTT + + (K − 1) RTT −
C C
Uguagliando questa espressione con quella analoga scritta poco sopra otteniamo anche l’espressione
di TA :
(W − 1) · MSS
TA = RTT −
C
Il tempo perso è quindi l’RTT meno il tempo utilizzato per spedire i dati (com’è ovvio aspettarsi). Si
ricorda che siamo nel caso di finestra costante (il W ’a regime’ è fisso e noto a priori) e si nota che la latenza
cresce:
• se K aumenta (molte trasmissioni dovuti a una grande quantità di dati o a una finestra troppo
piccola);
• RTT grande rispetto a MSS/C (molto tempo perso in giro per la rete).
La latenza tende invece al valore ottimo (cioè cala) se:
• K = 1 (una sola finestra contiene tutto il blocco dati e il termine TA non esiste);
(W − 1) · MSS
• → RTT (idem come sopra).
C

3.6.2 Finestra evolvente (dinamica)


Facciamo l’ipotesi che il server utilizzi inizialmente lo Slow Start (finestra iniziale: W = CW = 2). Come
sappiamo, ad ogni riscontro si ha W = W + 1 e quindi la finestra raddoppia ad ogni RTT (v. figura 3.16.
Sia quindi K la variabile che conta i RTT a partire da 1 seguendo la seguente relazione14

RTT numero k → W = 2k−1


13 L’S in figura è l’MSS.
14 Che è valida solo se lavoriamo unicamente in SS!!
3.6. LATENZA 39

Figura 3.16: Raddoppio della finestra in SS

La trasmissione dei dati può essere quindi suddivisa in due fasi:

• in una prima fase la finestra è ancora piuttosto piccola e abbiamo purtroppo dei tempi morti, perché
il tempo d’invio dei dati (che sono pochi) è molto piccolo rispetto al tempo che dobbiamo attendere
prima di avere la conferma ed allargare la finestra: W < S/C + RTT;

• nella fase successiva la finestra è abbastanza grande e da far sì che, all’arrivo della prima conferma,
ancora si stanno spedendo dei segmenti: W ≥ S/C + RTT. In questo regime la banda è sfruttata la
meglio.

Siano P0 i bit spediti durante la prima fase e P00 = P − P0 i bit spediti nella seconda. Se il ciclo k0 è
quello in cui termina la prima fase allora durante quest’ultima avremo trasmesso:

k0 k0
∑ 2i−1 · MSS [byte] ∑ 2i − 1 [segmenti]
i =1 i =1

Di lì in poi siamo nella seconda fase e quindi nel caso ottimo per la latenza. Sommando i contributi della
prima fase e della seconda otteniamo:

P00
 
0 MSS
L3 = 2RTT + k + RTT + =
C C
|{z}
| {z }
prima fase seconda fase

P00 P0 P0
 
MSS
= 2RTT + k0 + RTT + + − =
C |C {z C} C
P/C
k0
  ∑ 2i−1 · MSS
P MSS i =1
= 2RTT + + k0 + RTT −
C C C
40 CAPITOLO 3. MODELLI ANALITICI PER LE PRESTAZIONI DEL TCP
Elenco delle figure

1.1 La macchina a stati finiti che implementa il TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 6


1.2 Evoluzione dell’RTO secondo i due RFC illustrati. Il risultato è migliore tanto più si è vicini
alla linea rossa. Si noti che Jacobson ha dei grossi vantaggi quando la linea è stabile, mentre
si tiene dalla parte del sicuro quando non lo è . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Misurazione dell’sRTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4 Ambiguità nel calcolo dell’sRTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Duplicazione dei numeri di sequenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Il meccanismo a finestra fra segmenti ricevuti e segmenti non trasmessi. . . . . . . . . . . . . 13


2.2 La questione delle capacità e l’adattività del controllo di flusso . . . . . . . . . . . . . . . . . 15
2.3 Meccanismo di Slow Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Distinzione fra SS e CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Un esempio d’evoluzione della finestra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Effetto dell’approssimazione TSS << TCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Condivisione della risorsa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.8 L’algoritmo di fast recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.9 L’algoritmo di fast recovery (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.10 Il TCP classico e il Tahoe (cioè TCP + Fast Rec.) a confronto . . . . . . . . . . . . . . . . . . . 22
2.11 I protocolli TCP Reno e TCP New Reno a confronto . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Modello periodico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26


3.2 Modello periodico (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Andamento della finestra con perdite aleatorie . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Le variabili Yi e Ai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Le variabili aleatorie in gioco nel modello TD . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.6 Modello TD+TO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.7 Modello TD+TO+AW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.8 L’approssimazione introdotta dalla formula di AW . . . . . . . . . . . . . . . . . . . . . . . . 33
3.9 Modelli a confronto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.10 Influenza dell’RTT sul modello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.11 Influenza di AW sul modello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.12 Influenza di RTO sul modello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.13 I passi imprescindibili per effettuare un trasferimento dati . . . . . . . . . . . . . . . . . . . . 36
3.14 Esempio con W = 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.15 Schema esplicativo della formula di L2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.16 Raddoppio della finestra in SS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

41