Flow & Congestion Control

Congestion Control

Solitamente la causa è il tentativo di troppi hosts di inviare dati a ritmi

troppo elevati, questo causa overflow dei buffer dei router e tutto ciò che ne
deriva.

Esaminiamo 3 scenari differenti e vediamo le cause del congestionamento di rete:

1)

Abbiamo una connessione che condivide un singolo router(con buffer infinito,

quindi nessuna perdita), 2 senders e 2 receivers, la capacità del mezzo
trasmissivo è R e non ci sono ritrasmissioni.

Supponiamo che l’host A stia inviando dati sulla connessione a una frequenza
λ(in) byte/s(i dati sono detti originali poiché vengono mandati sulla
connessione 1 sola volta). Pertanto A invia dati a λ(in) byte/s, ignorando
l’overhead dovuto all’incapsulamento dei dati in segmenti da parte del livello
di sotto. L’host B si comporta allo stesso modo.

Illustrazione 2: throughput per

Illustrazione 1: Quando il tasso
connessione in funzione del tasso d'invio,
d'invio si avvicina alla capacità
fino a R/2 il throughput del ricevente
trasmissiva, il delay aumenta in
equivale al tasso d'invio; una volta
maniera esponenziale dovuto a
superati R/2 il thoughput non aumenta,
ritardi di accodamento del router
questo perchè la capacità del mezzo
trasmissivo è R ed è condivisa
2)

In questo scenario assumiamo che:

1. il buffer sia finito
2. le connessioni sono affidabili
3. ritrasmissioni di pacchetti dovuti a time-out

Consideriamo il caso in cui l’host A sia in grado di determinare, se il buffer

nel router abbia spazio o meno, in questo caso non abbiamo smarrimenti per cui
λ(in) = λ’(in) e il troughput della trasmissione λ(in), e visto che non abbiamo
ritrasmissioni abbiamo che la velocità di invio non supera R/2.

Illustrazione 3: i tre casi analizzati

Consideriamo un caso più realistico, il sender rinvia solo quando è certo che il
pacchetto sia andato perso(per far questo imposta un timeout molto alto), la
situazione è quella della seconda figura, abbiamo λ’(in) = R/2 e λ(out)=R/3,
abbiamo quindi costi maggiori dovuti alla ritrasmissione

Come ultimo scenario consideriamo il caso in cui il mittente possa andare il

timeout prematuro, in questo il caso il router dovrà ritrasmettere dati già
trasmessi, effetuando ritrasmissioni non necessarie, la figura 3 mostra i
thoughput nell’ipotesi che ogni pacchetto sia instradato mediamente due volte
dal router.
3) 4 sender 4 receiver, molteplici percorsi, ogni host offre un servizio di
trasmissione affidabile tramite ritrasmissioni e timeout

i router sono condivisi tra gli hosts per le connessioni, con valori molto
piccoli di λ(in) non abbiamo overflow e risulta essere uguale a il thoroughput
del ricevente, aumentando λ(in) abbiamo un conseguente aumento del λ(out).

as red λin’ increases, all arriving blue pkts at

upper queue are dropped, blue throughput g 0,poichè D
e A entrano in competizione tra di loro.

Il throughput si annulla poiché i router intermedi

perdono tempo nella trasmissione di pacchetti che
andranno buttati

Illustrazione 4: Il grafico mette

in relazione quello che si
trasmette rispetto a quello che
si riceve. All’inizio le due
grandezze vanno di pari passo,
poi quando quello che si riceve
raggiunge il suo apice, se non
si smette di aumentare la
velocità del mittente,
cominceremo a perdere troppi
pck fino a quando, i pacchetti
ricevuti saranno 0 causa
congestione.

Approcci:

1. end-to-end, i sistemi periferici regolano il traffico in base al

comportamento della rete(numero di ACK ricevuti), quindi il livello di
rete non fornisce alcun supporto
2. controllo di gestione assistito dalla rete, i router forniscono un
feedback(pacchetti speciali chiamati chock packets, inviati direttamente
dal router) esplicito al mittente sullo stato di congestione della
rete(non rispetta i criteri di modularità)
Nel secondo caso i feedback al mittente vengono forniti attraverso:

1. choke packet, uno speciale pacchetto di congestionamento inviato da router

a mittente
2. il router imposta uno speciale campo nel pacchetto

entrambi richiedono 1 RTT.

NB IP non fornisce feedback.

Controllo di congestione ATM ABR

Approccio TCP

Utilizza un approccio end-to-end, se TCP rileva poco traffico aumenta la

trasmissione, nel caso il traffico fosse elevato la diminuisce.

Riduzione della velocità TCP

Il meccanismo di controllo
della congestione TCP fa tener
traccia agli estremi di un
buffer di ricezione, uno di
invio e diverse variabili, tra
cui rwnd e LastByteRead di una
cwnd, che impone un vincolo
sulla velocità di traffico
sulla rete da parte del
mittente.

Illustrazione 5: estremi di una connessione TCP

La quantità dati massima per cui si
gli ACK precedenti è LastByteSent –
abbastanza grande da poter ignorare
quindi la quantità di pacchetti che
cwnd)
può continuare a inviare senza aver ricevuto
LastByteAcked <= cwnd(assumiamo che rwnd sia
il vincolo della finestra di ricezione,
non hanno ricevuto riscontro è limitata da

cwnd/RTT byte/s = velocità d’invio del mittente, ignorando perdità di pacchetti

e ritardi di trasmissione

Come si percepisce la congestione?

Consideriamo la congestione la perdità di pacchetto, il che si rileva con lo

scatto di un timeout o ACK duplicati(3), in presenza di congestione abbiamo
overflow dei buffer dei router, il chè causa la perdita di datagrammi che causa
timeout del mittente o ACK duplicati.
cwnd è modificato in base al tasso di arrivo degli ACK.

Il problema ora è stabilire a quale velocità trasmettere, bisogna trovare il

giusto compromesso tra bassa utilizzazione di banda(velocità bassa) e
congestione elevata(velocità alta).

Per stabilire la velocità trasmissiva bisogna seguire queste linee guida:

1. se un segmento viene perso, con la conseguente ritrasmissione, bisogna

diminuire la velocità di trasmissione, poiché sintomo di congestione
2. Quando arrivano gli ACK la cwnd può essere incrementata
3. Il mittente TCP invia segmenti aumentando la velocità trasmissiva finché
non si verifica una perdita, a questo punto rallenta e riprende ad
aumentare per verificare se il tasso di congestione è cambiato

Algoritmo TCP

Viene diviso in 3 parti:

1) Slow Start
la cwnd viene inizializzata a 1 MSS, a
seguito di ogni ACK, di segmento, viene
incrementata di 1 MSS, parte lentamente
(slow start), ma raddoppia la velocità
trasmissiva a ogni RTT, in maniera
esponenziale.

Quando termina la slow start:

• evento di timeout: cwnd viene riportato a 1, e riinizia slow start
• viene inizializzata la variabile ssthresh a cwnd/2(metà della finistra
quando si era verificata la congestione), quando la cwnd raggiungerà
ssthresh slow start terminerà e TCP entrerà in congestion avoiance
• 3 ACK duplicati, TCP opera una trasmissione rapida,per poi entrare in fast
recovery
 Illustrazione 6: riassunto slow start con automa a stati finiti

Congestion Avoiance

TCP quando entra in questa fase ha un valore di ssthresh, aumenta di 1 MSS ogni
RTT cioè cwnd+1/cwnd ogni ACK. A seguito di un timeout si comporta come slow
start, in caso di 3 ACK TCP dimezza il valore di cwnd aggiungendo 3MSS, quelli
degli ACK duplicati, ssthresh viene impostato a cwnd al momento della ricezione
degli ACK duplicati e entra in fast recovery.

Fast Recovery

Il valore di MSS è incrementato di 1 per ogni ACK ricevuto relativamente al

segmento perso, quando arriva un ACK per il segmento perso entra il CA dopo aver
dimezzato cwnd; se si verifica un timeout si entra in slow start cwnd viene
posto a 1 e sshtresh a cwnd/2
Il fast Recovery è implementato solo in TCP RENO

Retrospettiva controllo di congestione

Ignoriamo gli eventi di timeout e la fase di slow start, quindi il controllo di

congestione consiste in un incremento lineare di 1 MSS e un dimezzo
moltiplicativo di cwnd/2 ogni 3 ACK duplicati,per poi riprendere a salire
linearimente per capire se c’è ancora ampiezza di banda disponibile; questo da
luogo al comportamento a dente di sega del grafico sottostante.
 Illustrazione 7: Andamento AIMD

cwnd è gestita dall’utente

Throughput TCP

Ignorando le fasi di slow start dopo timeout, abbiamo che:

durante un dato intervallo di RTT la velocità di invio dei dati è funzione della
cwnd e RTT corrente; se l’ampiezza della finestra vale w e la frequenza
trasmissiva è w/RTT byte/s. TCP aggiunge 1 MSS a w ogni RTT finché non si
verifica una perdita W(valore di w durante la perdità), se W e RTT sono costanti
durante la connessione abbimo che il throughput varia tra W/(2xRTT) e W/RTT

ciò che succede in continuazione è : velocità sale a W/RTT; la velocità viene

incrementata di MSS/RTT a ogni RTT finché non torna a W/RTT

throughput(medio) = (0,75*W)

Connessioni a banda larga e TCP

Il controllo di congestione TCP è in continua evoluzione, questo perché la

maggior parte delle connessioni TCP di una volta trasportavano traffico SMTP,FTP
ecc… oggi internet è dominata da HTTP e il controllo di congestione di una volta
non va più necessariamente bene.
Supponiamo di voler inviare dati a 10Gbps, attraverso una connessione TCP con
segmenti da 1500 byte, per ottenere un throughput di 10Gbps abbiamo bisogno di
una finestra di congestione di 83 segmenti, e un fattore di perdita di 2^-10,
che è davvero molto molto poco.

Fairness

Abbiamo K connessioni TCP, ciascuna con un diverso percorso end-to-end, ma che

passano tutte nello stesso collegamento con capacità trasmissiva Rbps, che
costituisce un collo di bottiglia.
Gli altri collegamenti del sistema non sono congestionati.

I router devono gestire molte connessioni, se ogni host(supponiamo siano K)

vuole utilizzare il collegamento, ciò che dovrebbe fare il meccanismo di
controllo di congestione è dare velocità trasmissiva pari a R/K(equo). Questo
non è molto semplice poiché ogni gli host non si collegano contemporaneamente e
ogni host ha una propria finestra.

L’algoritmo di TCP(AIMD) è un algoritmo equo, per vederlo consideriamo un

esempio.
 ESEMPIO

Illustrazione 8: supponiamo che MSS e RTT siano uguali

Supponiamo che i due host debbano strasferire dati attraverso questo
collegamento, e che non vi siano altre connessioni TCP e UDP che attraversano
questo collegamento. Ignoriamo le fasi di slow start e ipotizziamo che le
connessioni lavorino in congestion avoiance per tutto il tempo.

Se AIMD sta suddividendo la banda

equamente allora il throughput
dovrebbe cadere lungo la
bisettrice, la somma dei due
throughput è R.

Illustrazione 9: throughput delle due connessioni

Supponiamo che le due connessioni TCP stiano utilizzando la banda, e

congiuntamente non arrivano a R, quindi aumentano la finestra di 1MSS per RTT,
successivamente potrebbero superare R, per cui vengono decrementate di 2 e poi
aumentano di nuovo di 1 MSS e così via, in questo modo garantiamo l’equità ma
nella pratica questo è quesi impossibile considerando, che ci sono nuove
connesioni ogni secondo, e quindi spingere la velocità di banda verso
R/2(fairness) è impossibile, anche tenendo conto del fatto che connessioni con
RTT inferiori sono in grado di prendere più velocemente la larghezza di banda.