Capitolo 1

TCP su reti mobili

1.1 TCP su reti sse

I protocolli di trasporto adabili come TCP sono stati messi a punto per reti tradiziona-
li che comprendono collegamenti cablati e host ssi. Questi protocolli presumono che la
congestione della rete sia la causa principale di perdite di pacchetti e ritardi insoliti. Il
protocollo TCP funziona bene su tali reti, adattandosi ai ritardi end-to-end e alle perdite di
pacchetti causate dalla congestione. Infatti, il mittente TCP utilizza gli ACK cumulativi che
riceve per determinare quali pacchetti hanno raggiunto il destinatario e fornisce adabilità
ri-trasmettendo i pacchetti persi.
TCP reagisce a qualsiasi perdita di pacchetti riducendo la dimensione della nestra di con-
gestione attraverso un approccio denominato diminuzione moltiplicativa. Grazie alla
diminuzione moltiplicativa viene evitata la congestione riducendo notevolmente il traco
generato. Quando, invece non ci sono perdite di pacchetti, ovvero vi è un comportamento
corretto, TCP aumenta gradualmente la dimensione della nestra, adottando un compor-
tamento additivo.

Nella fase iniziale si cerca di trovare velocemente il valore ottimale della congestion win-
dow. All'inizio (fase di slow start) si parte con una nestra pari ad un singolo segmento. Il
mittente TCP inizia trasmettendo il primo segmento dati, attendendo in seguito l'ACK. La
nestra raddoppia di dimensioni (e di conseguenza ne raddoppia anche la velocità trasmis-
siva) ad ogni RTT (Round Trip Time), no ad arrivare ad una soglia di congestione della
trasmissione. Raggiunta tale soglia la dimensione della nestra viene incrementata linear-
mente (incremento adattativo). Questo comportamento di TCP viene denito Cogestion
Advoidance.

Figura 1.1

Nella gura 1.1 si può notare come nella prima fase, detta slow start la nestra cresce in
modo esponenziale. In seguito avviene la fase di congestion advoidance, una volta supe-
rata la soglia di congestione (pari a 4).

1
Se si verica un errore nella fase di slow start la nestra viene riportata a 1, mentre se si
verica un errore nella fase di congestion advoidance, la nestra viene dimezzata.
Inoltre TCP è self-clocked, ovvero non richiede temporizzazione, dato che si utilizzano gli
ACK ad ogni trasmissione.

1.1.1 TCP: Fast Retransmit

Uno dei problemi in TCP è la tempestività di reazione in caso di errore. Per tempestività si
intende la capacità di risolvere (recovery) un errore il prima possibile, evitando che il timer
di ritrasmissione scada. Pertanto viene introdotto la tecnica di Fast Retransmit, la quale
anticipa lo scadere del timer di ritrasmissione. Tale scopo viene raggiunto ri-trasmettendo il
segmento perso dopo la ricezione di 3 ACK consecutivi fuori sequenza. In seguito il sender
riceverà un ACK cumulativo da parte del receiver.
Pertanto non si aspetta che scada il timeout prima di rinviare il pacchetto perso, ma grazie
agli ACK cumulativi, la perdita viene tempestivamente risolta.
Nell'esempio in gura 1.2, si può notare che il segmento 3 viene perso. Alla ricezione del
segmento 4, il ricevente capisce della perdita e inoltra nuovamente l'ACK dell'ultimo pac-
chetto ricevuto prima del segmento mancante (ACK_2). Quando il ricevente riceve altri
pacchetti diversi dal segmento 3, risponderà con l'ACK dell'ultimo pacchetto in sequenza
ricevuto (ACK_2). Alla ricezione del terzo ACK consecutivo fuori sequenza, il mittente si
preoccuperà di rinviare il pacchetto mancante prima dello scadere del RTO. Il sender riceverà
inne l'ACK cumulativo con il numero di sequenza pari a 6.
Inoltre con la Fast Retransmit la fase di slow start non è necessaria.

Figura 1.2

1.2 TCP su reti mobili

Come già detto, TCP è un protocollo di trasporto adabile ottimizzato per reti tradizio-
nali, in cui si vericano perdite di pacchetti principalmente per problemi di congestione.
Ultimamente è stato proposto di utilizzare TCP come protocollo di trasporto in una rete in
cui vi sono host mobili, i quali sono collegati mediante canali wireless. Ad esempio, in una
rete cellulare l'ultimo host è uno User Equipment collegato all'infrastruttura attraverso un
canale radio. Nelle infrastrutture così denite TCP può comportare alcune problematiche
sul canale radio. Questo a causa del suo comportamento propenso a considerare come errore

2
un evento dovuto alla congestione ed a trascurare quello legato ad un errore di trasmissione
sul canale sico (interferenze, crosstalk etc..).
Se l'errore è dovuto dalle caratteristiche intrinseche del canale sico, la soluzione di limita-
re la nestra di congestione è un'operazione inutile e non ottimale, dato che viene ridotto
l'utilizzo del canale stesso. Il problema in questi casi consiste solo nella ritrasmissione dei
pacchetti persi. Una delle soluzioni naive sarebbe quella di eliminare la fase di riduzione
della nestra in caso di errore. Tuttavia, il problema di tale soluzione sarebbe quello di
rendere impossibile l'utilizzo del protocollo TCP su una rete cablata ssa.
Vi sono diversi aspetti negativi legati ad un protocollo TCP tradizionale (TCP-RENO).
• Durante lo slow start vi è un sottoutilizzo del canale.

• Su un canale lossy (la probabilità di perdita dei pacchetti è maggiore) le perdite ven-
gono trattate come problemi di congestione, riducendo la nestra no a 1/2. Questo
comporta un sottoutilizzo del canale, l'incremento delle code di ingresso, la riduzione
del throughput e l'incremento del RTT.

1.2.1 TCP/IP in Mobile Environment

Figura 1.3

Nella gura 1.3 viene illustrato un ambiente mobile per TCP, in cui vi sono:
• un nodo FH collegato alla rete ssa (es. server);

• diversi nodi MSR, i quali sono punti intermedi. Tali nodi possono essere access point
wi oppure antenne dell'operatore telefonico.
• un nodo MH, il quale rappresenta il dispositivo mobile.

Vi sono due motivi che comportano ad una perdita su un canale radio in un ambiente mobile :
1) il canale è lossy (radio); 2) il dispositivo mobile si muove tra due celle (non può essere
risolto). Inoltre per movimento non si intende la semplice mobilità da una cella all'altra, ma
si intende anche la mobilità da un tipo di piattaforma radio all'altra. Ad esempio quando si
passa da una rete cellulare ad una rete wi (es. di casa), l'indirizzo IP associato al dispositivo
cambia e pertanto la connessione TCP cade completamente.

3
1.3 Tecniche per TCP su reti wireless
Recentemente, sono stati proposti per TCP diversi schemi per alleviare gli eetti delle perdite
(non legate alla congestione) su reti che hanno collegamenti wireless o simili ad alta perdita:
• End-to-end protocols;
• Link-layer protocols;
• Split-connection protocols;
• Hybrid protocols.

1.3.1 Protocolli end-to end

Sebbene su Internet sia utilizzata un'ampia varietà di versioni TCP, l'attuale standard de
facto per le implementazioni TCP è TCP-Reno. I protocolli end-to-end si collocano in una
logica in cui TCP rimane end-to-end per tutta la tratta che separa il sender dal receiver. Vi
sono tre meccanismi:
• TCP New Reno.
• Selective Acknowledgments (SACKs): anticipare la recovery dell'errore evitando la
riduzione della windows. Pertanto gli ACK vengono validati in modo selettivo (invece
che in modo cumulativo).
• Explicit Loss Notication (ELN): il sender è in grado di distinguere tra un errore di
congestione e altre forme di perdita. Questo permette di evitare l'abbattimento della
nestra inutilmente.

TCP New Reno. La dierenza tra TCP tradizionale e TCP New Reno sta nella ritra-
smissione dei pacchetti in caso di perdita. Mentre in TCP RENO la ritrasmissione viene
attraverso la metodologia Fast Retransmit per ogni segmento perso. In TCP NEW-RENO la

Figura 1.4: TCP RENO (a sinistra) vs TC-NEW-RENO (a destra)

procedura Fast Retransmit viene eettuata solo alla prima perdita (segmento 3), mentre per
tutte le altre perdite (es. segmento 7) la ritrasmissione del pacchetto avviene al primo ACK
fuori sequenza. Infatti come si evince dalla gura 1.4, alla ricezione dell'ACK_6 il Sender
capisce che il segmento 7 non è stato ricevuto e quindi lo ritrasmette immediatamente senza
aspettare ulteriori ACK fuori sequenza.

4
TCP con Selective ACK. Dalla gura 1.5 si può notare che l'ACK è costituito da due
campi, ovvero nel primo campo viene riportato il numero dell'ultimo segmento ricevuto cor-
rettamente (sequenza corretta), mentre nel secondo viene riportato il numero di sequenza del
segmento attualmente ricevuto secondo il usso. Quando il Sender riceve un ACK con ultimo
segmento diverso da quello attualmente ricevuto (ACK 2,4), capisce che deve ritrasmettere.
Questa tecnica funziona bene anche con perdite muliple. Tuttavia, considera ancora la con-
gestione come causa dei pacchetti persi. Inoltre, funziona bene quando l'ordine dei segmenti
è rispettato. Infatti, in una rete ssa il disordine è possibile a causa delle diverse route di
instradamento. In una rete wireless i pacchetti non possono viaggiare in disordine. Inoltre
è utile ridimensionare il timer di ritrasmissione del Sender in modo tale da permettere di
anticipare la ritrasmissione prima dello scadere del timer.

Figura 1.5: TCP con Selective ACK

TCP con ELN. Viene aggiunta una L che indica una perdita di segmenti da parte del
Receiver. In questo caso non si abbatte la nestra di congestione ed inoltre non viene
anticipata la ritrasmissione. Tuttavia, con tale tecnica non è possibile distinguere una perdita
da un semplice ritardo.

Figura 1.6: TCP con ELN

5
1.3.2 Link Layer Protocols

Nelle tecniche end-to-end non è ancora chiaro come esplicitare gli errori. Questo non può
essere fatto se non utilizzando il livello 2, perché è proprio sul link layer (sulla tratta radio)
che si riesce a capire se si ha o meno un errore. Questo permette di noticare al livello
superiore che è stato rilevato un errore e che la ritrasmissione deve essere eettuata senza
abbattere la nestra.
Lo sforzo per lavorare al livello 2 sarebbe quello di: costruire un protocollo di livello 2 capace
di dialogare con il livello 4 comunicando la rilevazione di errore (attraverso una explicit loss
notication), oppure costruire un protocollo di livello 2 che renda il link radio totalmente
adabile.

Figura 1.7: Schema Link Layer Protocols.

Nasce quindi la necessità di trasformare il link layer, che copre il canale radio, in un link
totalmente adabile. Se il livello 2 fosse adabile, non si avrebbe più la necessità di segnalare
gli errori ai livelli superiori. Questo comporterebbe, inoltre, l'eliminazione della situazione
in cui avviene l'abbattimento della nestra di congestione per una perdita su canale radio.
Tuttavia ciò non è sempre possibile, perché non è detto che si riesca a recoverare l'errore in
tempo. Infatti non è detto che si riesca ad evitare che l'end-point segnali dell'errore all'altro
end-point, il quale procederà con l'abbattimento della congestion window.
A tal proposito sono stati proposti diversi approcci.

LL Cumulative ACK. Il primo metodo (più semplice) per rendere adabile il canale
radio a livello 2 è quello di introdurre un sequence delle frame ed un timer di ritrasmissione
entro il quale aspettare l'ACK di ricezione. Se allo scadere di questo timer il sender non
riceve alcun ACK in risposta, allora si prepara a ritrasmettere la frame mancante. Ogni qual
volta che ritrasmetto una frame, attivo il timer che viene resettato alla ricezione dell'ACK
relativo al frame ritrasmesso. In seguito il sender passerà alla trasmissione della frame suc-
cessiva.
Per evitare ritrasmissioni, il livello 2 dello MSR crea un timer più piccolo rispetto a quello
del mittente. In questo modo se qualche frame viene persa il MSR è in grado di rinviarla
prima che il timer del mittente (al livello 4) scada. Questo permette di evitare che il sistema
si attivi per abbattere la nestra di congestione.
Un trucco per realizzare protocolli di livello 2 di questo tipo è quello di semplicare il pro-
tocollo ottimizzando l'uso del ACK.
Il livello 2 del destinatario, quando riceve un frame, non invia un ACK al livello 2 del MSR
ma aspetta che sia il livello 4 (TCP) ad inviarlo verso il Sender (FH). In questo modo si
risparmia un frame sul canale. Il livello 2 del MSR "spia " (snooping) il pacchetto di livello 4
inviato dal Receiver verso il mittente, per vedere se è contenuto l'ACK relativo alla sequenza

6
appena trasmessa. Tale tecnica è denominata LL ACK by Snooping TCP ACK. Si può
evincere, pertanto, che la gerarchia dei protocolli e dell'indipendenza del servizio vanno a
sparire. Poiché il livello 2 eettua uno snooping dei segmenti dei livelli superiori.

Figura 1.8: LL Cumulative ACK.

Questo meccanismo può essere esteso alla gestione di una nestra di trasmissione. Questo
perché non è più necessario aspettare un ACK di avvenuta ricezione di ogni singolo frame
(non è eciente). Per cui attraverso un approccio LL Cumulative ACK è possibile inviare
anche a livello 2 l'intera nestra di trasmissione (es. in gura 1.9 sono 4 frame) e aspettare
i relativi ACK.
Nella gura 1.9, durante la trasmissione dell'intera nestra, il segmento 1 viene perso, mentre
i segmenti 2,3,4 arrivano a destinazione. A questo punto il Receiver invia verso il Sender gli
ACK relativi. Al primo ACK_0 il livello 2 dello MSR ritrasmette il frame 1, poiché fuori

Figura 1.9: LL Cumulative ACK con nestra.

sequenza. Tuttavia si noti che l'ACK_0 arriva lo stesso all'end-point (Sender). L'obiettivo è
quello di far sì che il sender riceva gli ACK di tutti i 4 segmenti prima che il timer TCP scada
(il primo), oppure prima che venga attivata la Fast Retransmit. Infatti come si evince, il
Sender riceve due ACK_0. Se ricevesse il terzo ACK_0, verrebbe avviata la Fast Retransmit
con la conseguenza di abbattimento della nestra di congestione, rendendo tutto il lavoro
eettuato al livello 2 inutile. Pertanto l'obiettivo è quello di riuscire ad trasmettere tutta

7
la nestra senza che l'errore sul canale radio emerga al livello 4, ovvero riuscire a risolvere
l'errore mediante una ritrasmissione locale.

Tuttavia, tale tecnica non sempre evita l'abbattimento della nestra di congestione. Ci
sono situazioni (in base a come si gestisce il processo e/o come si sincronizzano gli eventi)
che non permettono di garantire di raggiungere l'obiettivo. Si noti la gura 1.10, anche in
questo caso viene perso il segmento 1. Mentre i frame 2,3,4 vengono correttamente ricevuti
e validati. Tuttavia, nonostante il link layer di MSR (mediante il primo ACK_0) capisce
che vi è stata una perdita del primo frame, questo non è suciente. Infatti la ritrasmissione
arriva troppo tardi, poiché al livello 4 del Sender sono già arrivati 3 ACK consecutivi fuori
sequenza, i quali faranno scattare la Fast Retransmit per il segmento 1 e l'abbattimento
della nestra di congestione. Un modo per evitare ciò è quello di adottare la tecnica di LL
Selective ACK.

Figura 1.10: LL Cumulative ACK con abbattimento di congestione.

LL Selective ACK. Tale tecnica consiste nell'implementare al livello 2 l'approccio di

selective ACK per accelerare la procedura di ritrasmissione. Tuttavia, come si evince dall'e-
sempio, la soluzione può non essere ottimale. Infatti se il timer scade di conseguenza la ne-
stra di congestione viene abbattuta. L'uso del selective ACK riduce la casualità dell'errore,
ma non va ad eliminare del tutto l'abbattimento della nestra di congestione.

Figura 1.11: LL Selective ACK

8
LL TCP Aware. Tale tecnica permette di evitare che la nestra di congestione venga
abbattuta in caso di errore sul canale radio. Il modo per garantire che il Link Layer risolva
totalmente un errore dovuto a perdita di frame sul canale radio è quello di introdurre un LL
Aware, ovvero un livello 2 totalmente in grado di operare come se fosse TCP.
Pertanto l'idea di snoopping dei frame viene superata, ma al suo posto viene introdotto un
livello 2 totalmente consapevole delle funzionalità del livello 4. Quando vi è una possibilità
che si possa generare un abbattimento della nestra di congestione, il livello 2 interviene
modicando il comportamento di TCP. Andando persino ad interrompere il usso di seg-
menti TCP (come avviene nella gura 1.12). Il Sender invia una nestra di trasmissione di
5 frammenti. Sulla tratta canale radio i segmenti 1 e 2 vengono persi. Quando il 3 segmento
arriva al livello 4 del Receiver, quest'ultimo risponde con un ACK (0,3). Il quale indica
che il numero di sequenza corretto, però ha ricevuto il numero 3. Anche per la ricezione
dei segmenti 4 e 5, il Receiver si comporterà allo stesso modo. Quando il MSR riceve il
primo ACK fuori sequenza (0,3) si occuperà di ritrasmettere il frame 1. Come si può notare
dalla gura, ogni qualvolta che il MSR riceve un ACK fuori sequenza quest'ultimo non lo
propaga all'altro end-pointo della connessione TCP. Ma la recovery viene direttamente ge-
stita al livello 2 per poi scartare l'ACK fuori sequenza. Pertanto il usso degli ACK verso
l'altro end-point viene interrotto nché non viene risolto l'errore. Solo nel momento in cui
viene inviato l'ACK corretto, ovvero in sequenza, il livello 2 si occupa di propagarlo ai livelli
superiori verso destinazione.
Con questo approccio l'errore viene risolto localmente, evitando che i segmenti raggiungano
l'altro capo della connessione TCP e pertanto evita l'abbattimento della nestra di conge-
stione.
Il vantaggio di tale tecnica è quello che si risolve totalmente il problema di TCP su canale
radio in modo eciente ed ecace. Tuttavia, complico il livello 2 e richiedo che gli end point
operano su un TCP che si comporti come descritto. Quindi, l'unica soluzione che risolve il

Figura 1.12: LL TCP aware

problema di TCP su canale radio è quella Aware, la quale intercetta tutto il traco TCP
al livello 2. È ecace perché andando ad interrompere tutto il traco di ritorno tra i due
end-point TCP, evita l'abbattimento della nestra. I problemi di errore vengono risolti solo
a liv 2 per poi passare all'end point solo informazioni corrette.

1.3.3 Split-connection Protocols

Questi protocolli evocano una situazione rappresentata in gura 1.13, ovvero una connessio-
ne TCP che ha come end point un device sso (FH) e uno mobile (MH). Tale connessione
TCP è caratterizzata dal fatto che utilizza un link radio per l'ultimo hop tra il punto di
accesso MSR (es. BS) e il device mobile (MH).

9
La split connection, divide in 2 la connessione TCP. Quindi, non si ha più un'unica connes-
sione tra MH e FH, ma questa viene divisa in due tratte in cui:

Figura 1.13: Split-connection Protocols

• la prima (MH-MSR), opera solo sul canale radio (Special TCP ). Denito Special perché
non reagisce all'errore con l'abbattimento della nestra;
• la seconda (FH-MSR), opera su rete ssa con TCP tradizionale.
Lo svantaggio di tale tecnica è che il MSR deve essere in grado di "cucire" i due end-point
delle connessioni.

I-TCP: Indirect TCP. La connessione TCP è caratterizzata da una quintupla (Porta

sorgente, Porta destinazione, IP sorgente, IP destinazione, protocol selector). L'obiettivo è
quello di cucire le due tratte TCP. Pertanto è necessario riuscire a trasferire lo stato (pallini
azzurri su MSR) delle BS in caso di fase di Handover (freccia rossa tra MH-MSR2).

Figura 1.14: Indirect TCP

Come si può rendere la comunicazione trasparente tra due end-point quando ci sono in mezzo
delle BS? Il device MH deve comunicare con FH. Il dispositivo MH comunica con MSR1, il
quale converte il protocollo Special TCP con quello tradizionale con il quale poi comunicherà
con FH. Nel caso in cui MH cambia BS (fase di handover), il MSR1 a cui era collegata in
precedenza congela lo stato TCP delle sue connessioni. Questo stato viene inviato alla nuova
BS (MSR2) a cui il dispositivo mobile è ora collegato. In questo modo la comunicazione può
continuare.
Tale approccio richiede una stretta negoziazione tra le due MSR, poiché è necessario passare
lo stato. Trasferendo lo stato il protocollo è anche in grado di sanare errori creati durante
la fase di Handover (perdita dei pacchetti). Questo è fatto da TCP special (es. SACKs
or ELN). Pertanto la connessione TCP classica rimane ouscata dai problemi che si creano
sulla tratta tra mobile device e MSR1.
Procedura di HANDOFF: come migrare da una BS all'altra. Come già detto, ogni BS

10
invia il segnale di Beacon sul canale radio, il quale viene ricevuto da tutte le stazioni radio
vicine. Nella gura il dispositivo Mobile è collegato alla BS1, una volta ricevuto il Beacon
da una nuova BS (es. BS2), controlla qual è il segnale più potente. Nel caso in cui la
BS2 abbia un segnale maggiore della BS attuale, il MH migrerà sulla nuova BS. Per far
ciò, MH comunica alla nuova BS (BS2) le sue credenziali e la lista delle connessioni aperte
con i dispositivi. Tali informazioni vengono validate. La BS2 negozia il trasferimento delle
connessioni dalla vecchia stazione (BS1) verso di lei. La BS1 congela le connessioni aperte
e invia alla nuova BS lo stato attuale di MH. La comunicazione viene validata. A questo
punto la BS1 chiude la connessione con MH, mentre la BS2 può iniziare a comunicare con
esso.

Figura 1.15: Procedura di Hando

1.3.4 TCP VEGAS

TCP Vegas evita di dividere in due la connessione. Quindi opera sulla stessa connessione,
agendo sulla gestione della tecnica di ritrasmissione e sulla gestione del controllo di usso
(gestione della nestra di trasmissione), in modo tale da ottimizzare il comportamento di
TCP.
L'innovazione riguarda:
• la fase di ritrasmissione

• la fase di slowstart

• la gestione della nestra di congestione. In tal caso usa un'approccio di Congestion

Advoidance, piuttosto che di controllo della congestione. Pertanto predice ed evita la
congestione prima che occorra.
Per quanto riguarda la fase di ritrasmissione, l'approccio Vegas misura in modo mania-
cale il Round Trip Time segmento per segmento. Dove per RTT si intende il tempo che
intercorre tra l'invio del segmento e la ricezione del relativo ACK. Pertanto Vegas misura il
RTT del segmento 0 e lo conserva (in un registro) come RTT minimo misurato nora. Come
si può notare dalla gura 1.16, per ogni segmento inviato viene misurato il RTT. Ad ogni
misurazione viene confrontato il RTT misurato con il RTT minimo attuale (es. RTT del
segmento 0), se quello misurato è minore del minimo attuale, il valore di RTT_min viene
aggiornato al nuovo valore.
La misurazione degli RTT viene utilizzata per la politica di ritrasmissione. Si supponga che

11
 Figura 1.16: Tecnica di ritrasmissione Vegas

un segmento venga perso (es. segmento 3) e per il quale non si riceva l'ACK relativo. Appe-
na il Receiver riceve il segmento 4, questo risponde con un ACK fuori sequenza (ACK_2).
Inoltre, come già detto, ad ogni invio di segmento viene settato un timer in base alle misu-
razioni dei timer precedenti. Quindi, anche per il segmento 3 viene settato un timer. Se allo
scadere di quest'ultimo il Sender non riceve un ACK, vuol dire che vi è un problema legato
alla trasmissione del segmento. Questo perché la misurazione del RTT non può discostarsi
di tanto da quelli precedentemente misurati.
Pertanto, la ritrasmissione di un segmento in Vegas avviene se si vericano due condizio-
ni: 1) vi è un ACK fuori sequenza (rst duplicate ACK ) e 2) il timer del segmento scade
(Timeout ). Queste due informazioni sono sucienti per far sì che il Sender eettui la ritra-
smissione del segmento perso (es. segmento 3).
Il nuovo meccanismo di gestione della ritrasmissione è applicabile anche per perdite multiple
di segmenti. Questo è possibile grazie alla misurazione granulare-ne del RTT per la gestione
immediata dei fuori sequenza, la quale consente a Vegas di anticipare subito la ritrasmissio-
ne dei segmenti. Questo permette la riduzione dei tempi di recovery in caso di errori e, se
ben gestita, permette anche di evitare di ridurre immediatamente la nestra di congestione
(riducendo di conseguenza il througput).
Per quanto riguardo la gestione della congestione, Vegas è meno reattivo ai cambiamenti
dovuti all'errore e utilizza una gestione della nestra più smurf e meno legata alla rilevazione
di un errore.

Figura 1.17: Tecnica di Congestion avoidance Vegas

Si supponga (gura 1.17) di avere un Sender e un Receiver. Quando il Sender manda il seg-

12
mento_x deve aspettare il relativo ACK. Pertanto viene fatto partire il RTT per misurare
il tempo che intercorre tra spedizione e ricezione del relativo ACK.
Usando Vegas, il RTT minimo nora misurato viene memorizzato all'interno di un registro
RTT Base. Se ad esempio vengono inviati sulla connessione 100 segmenti, in RTT Base
viene inserito il campionamento minore misurato di tutti gli RTT. Quindi in BaseRTT,
Vegas inserisce il minimo di tutti gli RTT misurati e questo permette di avere una stima
della trasmissione nelle condizioni migliori (possibili) di rete (che corrisponde alla minore
probabilità di congestione durante il tempo di vita della connessione).
Tutte le altre misure di RTT (RTTy ) sono le misurazioni di RTT associate ai singoli seg-
menti.
Durante la fase di RTT che intercorre dalla spedizione di un segmento alla ricezione dell'ACK
relativo, il Sender, usando la nestra di trasmissione, può mandare segmenti all'interno di
essa (es. all'interno di RTTy vengono inviati una sequenza di segmenti). Da ciò si presuppo-
ne che è possibile anche contare il numero di byte che il Sender riesce ad inviare all'interno
della nestra stessa per il tempo che sta misurando. Quindi, vi è un continuo monitoraggio
non solo del RTT ma anche della quantità di dati (in byte) che è possibile spedire all'interno
del tempo misurato.
Queste misurazioni vengono in seguito utilizzate per stimare il throughput ideale (S ex-
pected) e quello attuale (S actual) sulla rete. S expected è ottenuto come il rappor-
to del numero di byte in transito sul RTT minimo (RTTBase), ovvero S _expected =
CW DN (n of byte in transit)/BaseRT T . Questo throughput ideale è tanto maggiore
quanto è minore il BaseRTT. Quindi più piccolo è il RTT, migliore sarà il throughput otte-
nuto con la nestra di congestione attuale.
Il throughput attuale, ovvero quello misurato costantemente ad ogni segmento spedito, è
legato al rapporto della nestra attuale sul RTT sperimentato per il segmento y. Quindi, S
actual è ottenuto da S _actual = amount of data/RT T y .
TCP Vegas lavora sulla dierenza tra S expected e S actual. La dierenza non è mai minore
di 0, altrimenti il RTT sarebbe inferiore al Base RTT. Infatti se fosse 0 vorrebbe dire che il
RTT misurato sarebbe il nuovo BaseRTT. Al massimo la dierenza è uguale 0.
TCP Vegas utilizza il concetto di stima e predizione della congestione per ridimensionare la
nestra. Prevenzione perché inviando segmenti è possibile osserva se il RTT che campiono
tende a salire (tendenza a congestione).
Per far ciò TCP Vegas pone due valore soglia α e β (entrambi >0). Se il valore della dif-
ferenza tra il throughput ideale e quello attuale rimane all'interno di questi due valori (α e
β ), allora il Sender continua a spedire senza eettuare modiche all'interno della nestra di
congestione. Appena la dierenza scende sotto la soglia β (tentativo di RTT di salire costan-
temente), allora TCP riduce leggermente la nestra di congestione. Se invece la dierenza è
molto vicino al valore atteso (α), allora TCP tenta di aumentare la nestra. Quindi l'uso di

Figura 1.18: Tecnica di Congestion avoidance-soglia.

Vegas permette di ridurre gli eetti negativi di TCP lavorando al livello 4.

I problemi di TCP su canali wireless non verranno risolti con i primi 3 meccanismi, ma verrà
risolto con tecniche ibride. Ad esempio politiche end-to-end ma applicate a livello 7.

13