Controllo di flusso e di congestione nel TCP

Controllo di
congestione
1
Timeout
2
D: come fissare un valore per il timeout in TCP?
• troppo corto: timeout prematuri, ritrasmissioni
non necessarie
• troppo lungo: reazione lenta a perdite di segmenti
• ancora peggio: RTT ha notevoli fluttuazioni
RTT
3
Stima di RTT
D: come stimare RTT?
• SampleRTT: tempo misurato dalla trasmissione del segmento
sino alla ricezione dell' ACK
– si ignorano le ritrasmissioni ed i segmenti con ACK
cumulativi
• SampleRTT varia notevolmente, si vuole un RTT stimato che
sia “smoother”
– si usano diverse misurazioni recenti, non soltanto il
SampleRTT corrente, e si fa la media
• Se si considera, però, soltanto la media di SampleRTT, si
genereranno ancora molti timeout a causa delle notevoli variazioni
della rete: bisogna tener conto anche della varianza
4
Varianza
1. Se la velocità dei dati sulla connessione TCP è
relativamente bassa, il ritardo di trasmissione sarà
grande rispetto al tempo di propagazione, e la
varianza in ritardo dovuta alla varianza delle
dimensioni dei datagrammi IP sarà significativa
(proprietà dei dati e non della rete)
2. Il traffico può cambiare bruscamente a causa del
traffico generato da altre sorgenti, e così l'RTT
3. Uso del privilegio di ACK cumulativi o ritardi di
elaborazione alla destinazione
5
Stima della media
EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT
• exponential weighted moving average EWMA
• l'influenza di un dato sample diminuisce in modo
esponenziale rispetto alla distanza dal sample corrente
• tipico valore di x: 0.125
Stima della varianza
Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|
6
1 k +1
ARTT ( k + 1) =
RTT (i )
∑
k + 1 i =1
k
1
ARTT ( k ) +
RTT ( k + 1)
=
k +1
k +1
SRTT ( k + 1) = (1 − x ) SRTT ( k ) + xRTT ( k + 1)
= xRTT ( k + 1) + x (1 − x ) RTT ( k ) +
x (1 − x ) 2 RTT (k − 1) + ... + x (1 − x ) k RTT (1) +
(1 − x ) k +1 RTT (0)
7
0.5
Valore dei coefficienti
0.4
x=0.5
x=0.125
0.3
0.2
0.1
0.0
1
2
3
4
5
6
7
8
9
Età di osservazione
10
8
Algoritmo di Jacobson
EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT
Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|
Timeout = EstimatedRTT + 4*Deviation
9
RTT e Timeout
timeout
round-trip time
10
Congestione
11
•Il controllo della congestione può essere considerato
come l'uso efficiente della rete ad alto carico
• La congestione avviene quando il numero di
pacchetti trasmessi (immessi nella rete) comincia ad
approssimare la capacità di trattamento di pacchetti da
parte della rete stessa
• Quando l'utilizzazione delle linee in ingresso ai
nodi supera l'80%, e/o quando la velocità con cui
arrivano i pacchetti eccede la velocità con cui possono
essere trasmessi, la lunghezza delle code cresce in
modo allarmante
12
Congestione:
• informalmente: “troppe sorgenti che inviano
troppi dati troppo rapidamente perchè la rete
riesca a trattarli”
• differente da controllo di flusso!
• manifestazioni:
– pacchetti persi (buffer overflow ai router)
– lunghi ritardi (code nei router)
13
Throughput normalizzato
Prestazioni ideali
Carico normalizzato
14
Ritardo
Carico normalizzato
15
Prestazioni in pratica
Il caso ideale assume buffer infiniti ed assenza di overhead per controllo di
congestione
Prestazioni in pratica (buffer finiti)
• Punto A: alcuni nodi possono sperimentare congestione severa; inoltre
messaggi di routing per evitare aree congestionate
• Punto B: molti più nodi in congestione severa (buffer pieni); ritrasmissioni per
pacchetti con ACK in ritardo
Throughput normalizzato
•
Congest.
moderata
A
Congestione
severa
B
1.0
Carico normalizzato
16
Approcci al controllo
della congestione
Due approcci di larga massima:
Controllo di congestione
Controllo di congestione
assistito dalla rete:
end-to-end:
• i router forniscono feedback
• assenza di un feedback
agli end system
esplicito dalla rete
– singolo bit indicante
• congestione dedotta dalle
congestione (SNA,
perdite e dai ritardi
DECbit, TCP/IP ECN,
osservati dal sender
ATM)
• approccio seguito dal TCP
– velocità esplicita a cui il
sender dovrebbe
trasmettere
17
Meccanismi di controllo
della congestione
• Backpressure: può essere usata solo in reti che
permettono controllo di flusso hop-by-hop (X.25 si; Frame
Relay, ATM, IP no)
• Choke packet: pacchetto di controllo trasmesso
direttamente alla sorgente (es. source quench in ICMP –
Internet Control Message Protocol)
• Segnalazione implicita: uso di controllo di flusso endto-end (cioè a livello di trasporto, come in TCP, o di data
link LAPF control in Frame Relay), basato sul
riconoscimento di ritardi aumentati e perdite di pacchetti
da parte dell'end system sorgente
18
• Segnalazione esplicita: la rete avverte gli end system di
congestione crescente e gli end system riducono il carico;
opera su reti orientate alla connessione
• Backward
• Forward (invio di eco alla sorgente o controllo di flusso
ad uno strato superiore (TCP)): alterazione di bit in
pacchetti dati o invio di pacchetti di controllo separati
• Binary, Basato su credito, Basato su velocità
19
Implicito (delay,scarto)
policing
backpressure
Choke packet
source
Esplicito (binario,credito,velocità)
destination
Meccanismi per il controllo della congestione
20
Messa al passo di segmenti TCP
Sorgente
Segmenti di dati
Destinazione
Segmenti di ACK
Flusso determinato da congestione della rete
Pr=Pb e quindi Ar=Pr=Pb, Ab=Ar=Pb, As=Ab=Pb, ed infine Ps=As=Pb
21
Sorgente
Segmenti di dati
segmenti di ACK
Destinazione
Flusso determinato dal sistema di destinazione
22
• Gli ACK di ritorno funzionano da segnali regolatori. Nello
stato stazionario, dopo un burst iniziale, la velocità dei
segmenti del sender è uguale a quella di arrivo degli ACK.
Così la velocità dei segmenti del sender è uguale a quella del
link più lento lungo il cammino. In questo modo, il TCP
sente automaticamente il collo di bottiglia e regola il suo
flusso di conseguenza. Questo è il cosiddetto comportamento
self-clocking di TCP
• Questo comportamento è identico se il collo di bottiglia è al
receiver, così la sorgente non ha modo di conoscere se la
velocità di messa al passo a cui essa riceve gli ACK rifletta lo
stato della internet (controllo di congestione) o lo stato della
destinazione (controllo di flusso). Nel primo caso, dovrebbe
trasmettere ancor più lentamente del passo degli ACK per
aiutare la rete ad uscire dalla congestione, nel secondo non
c'è vantaggio a ridurre ulteriormente la velocità
23
• L'uso di GBN o SR per il recupero da errori/perdite
fornisce automaticamente anche una forma piuttosto
efficace di controllo di flusso/congestione
– Se la congestione monta ed aumentano i ritardi, gli ACK
sono emessi in ritardo ed il sender viene rallentato
– Se il receiver vuole ricevere pacchetti meno rapidamente,
può semplicemente ritardare l'invio degli ACK
• La combinazione di ACK con il controllo di flusso ha
però alcune limitazioni
– Il posporre l'invio di ACK può causare anche ritrasmissioni
non necessarie dovute a timeout
• Possibile approccio (e quello impiegato dal TCP):
disaccoppiare gli ACK dalla concessione del permesso
di invio di ulteriori unità di dati (il receiver manda due
numeri come feedback al sender!!!)
24
Controllo di
congestione
25
Controllo di congestione in
TCP
• IP non fornisce alcun meccanismo per rilevare, tanto meno
per controllare, la congestione
• TCP fornisce solo controllo di flusso end-to-end e può solo
dedurre con mezzi indiretti la presenza di congestione nella
internet. Tale conoscenza, inoltre, è inaffidabile
• La definizione dei parametri per il controllo di flusso e di
errore istante per istante (timeout e dimensione della
window), unitamente alle politiche di ritrasmissione, può
avere effetti gravissimi sull'insorgere della congestione, come
anche sulla prevenzione ed il ripristino dalla congestione
stessa: sono state così sviluppate delle tecniche di gestione
del timer di ritrasmissione e della window di trasmissione
finalizzate al controllo di congestione
26
Gestione del
Timeout
27
Algoritmo di Karn
• usare l'algoritmo di Jacobson per il calcolo del timeout
sino a quando non avviene una ritrasmissione
• fare backoff ad ogni ritrasmissione: timeout = 2x timeout
• riprendere l'algoritmo di Jacobson quando finiscono le
ritrasmissioni, cioè quando viene ricevuto un ACK di un
segmento non ritrasmesso
28
Gestione della
Window
29
• Receiver Window: anche nota come Advertised
Window, usata dal receiver per informare circa lo
spazio disponibile di buffer
• Congestion Window: il suo valore dipende dalla
congestione di rete così come è percepita dal
sender TCP
• La window del sender è min (CongWin, RcvWin)
LastByteSent – LastByteAcked <= min(CongWin, RcvWin)
30
• “provare” per conoscere la
bandwidth utilizzabile:
– idealmente: arrivare a
trasmettere il più
velocemente possibile
(=CongWin la più grande
possibile) senza avere
perdite. Per questo:
• partire da una CongWin
piccola ed aumentarla sino
ad avere perdite
(congestione)
• appena si hanno perdite:
diminuire CongWin,
quindi ricominciare a
provare (aumentandola)
• due “fasi”
– slow start
– congestion avoidance
• variabili importanti:
– CongWin
– Threshold:
definisce la soglia tra
la fase di slow start e la
fase di congestion
avoidance
31
Slowstart
32
TCP Slowstart
Slowstart
initialize: CongWin = 1
Threshold = 8
for (ogni ACK ricevuto)
CongWin++
until (perdita OR
CongWin > Threshold)
• crescita esponenziale (rispetto a RTT) in
window size (non così lento!)
• evento di perdita: timeout (Tahoe TCP)
e/o tre ACK duplicati (Reno TCP)
RTT
Host A
Host B
one segm
ent
two segm
ents
four segm
ents
time
33
Congestion
Avoidance
34
TCP Congestion Avoidance
Congestion avoidance
/* sl w o st
ra t è f i in t a
*/
/* CongWin > Threshold */
Until (perdita) {
ogni w ACK ricevuti:
Congwin++
}
Threshold = CongWin/2
CongWin = 1
effettua slowstart 1
1: TCP Reno salta slowstart (fast
recovery) dopo tre ACK duplicati
Congestion avoidance
Slow start
Round-trip times
•AIMD: additive increase, multiplicative decrease
– aumenta la window di 1 ad ogni RTT
– diminuisce la window di un fattore 2
quando ci sono perdite
35
Timeout
Round-trip times
36
Fast retransmit
e Fast recovery
37
Fast retransmit e fast recovery
• TCP sender:”Un ACK • TCP esegue fast retransmit di
duplicato è causato da
un segmento perso prima che
un segmento perso o
il suo timer scada e comincia
soltanto da un segmento la fase di slow start (TCP
fuori ordine?”
Tahoe)
• Se il TCP sender riceve • TCP Reno (de facto TCP)
tre ACK duplicati,
impiega anche un
assume questa come
meccanismo di fast recovery
una indicazione che il
che essenzialmente salta la
segmento seguente il
fase di slow start dopo una
segmento riscontrato è
fast retransmission (la
stato perso
congestione dopo tutto è
moderata se sono ritornati
ACK multipli!!)
38
TCP/Reno: Big Picture
cwnd
TD
TD
TO
ssthresh
ssthresh
slow
start
congestion
avoidance
ssthresh
congestion
avoidance
ssthresh
congestion
avoidance
slow congestion
start avoidance
TD: Triple duplicate acknowledgements
TO: Timeout
39
Time
Procedura di controllo di congestione:
TCP Tahoe
Initialize:
cwnd <-- 1 (MSS);
Threshold <-- 8 (MSS)
State <-- Slow Start;
Case of:
ACK received in Slow Start:
cwnd <-- cwnd +1; /* “exponential ” increase of cwnd */
If cwnd > Threshold Then State= Congestion Avoidance;
ACK received in Congestion Avoidance:
If # Acks received = cwnd Then cwnd <-- cwnd +1; /* “linear” increase of
cwnd */
Timeout:
Threshold <-- cwnd/2;
cwnd <-- 1;
State <-- Slow Start;
40
Equità
41
Obiettivo di equità: se N sessioni TCP condividono lo stesso
bottleneck link, ciascuna dovrebbe ottenere 1/N della capacità
del link
conessioneTCP 1
connessione TCP 2
bottleneck
router
capacità R
42
Equità TCP
Due sessioni in competizione:
• additive increase: pendenza di 1 (W, e così il throughput, crescono
linearmente per entrambe le connessioni)
• multiplicative decrease: linee che passano per l'origine (W, e così il
throughput, si dimezzano per entrambe le connessioni)
Throughput connessione 2
R
Linea di piena
utilizzazione di
banda
Throughput connessione 1
Uguale condivisione di
banda
R
43
• il traffico UDP non è soggetto al controllo di
congestione TCP; alcune sorgenti UDP (es. telefonia
IP) possono abusare di questo privilegio per forzare
buffer overflow e così slow start su connessioni TCP
(esse sono TCP unfriendly!)
• applicazioni multicast usano UDP; anch'esse sono
TCP unfriendly
• alcune applicazioni (es. HTTP) possono aprire
diverse sessioni TCP in parallelo, ottenendo così un
vantaggio non equo
44