Controllo di congestione

Transcript

1 Controllo di congestione 1

2 Timeout 2

3 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

4 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

5 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

6 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: Stima della varianza Deviation = (1-x)*Deviation + x* SampleRTT-EstimatedRTT 6

7 7 1) ( 1 1 ) ( 1 ) ( 1 1 1) ( = + = + + = k RTT k k ARTT k k i RTT k k ARTT k i (0) ) (1 (1) ) (1... 1) ( ) (1 ) ( ) (1 1) ( 1) ( ) ( ) (1 1) ( 1 2 RTT x RTT x x k RTT x x k RTT x x k xrtt k xrtt k SRTT x k SRTT k k = + + = +

8 x=0.5 x=0.125 Valore dei coefficienti Età di osservazione 8

9 Algoritmo di Jacobson EstimatedRTT = (1-x)*EstimatedRTT + x*samplertt Deviation = (1-x)*Deviation + x* SampleRTT-EstimatedRTT Timeout = EstimatedRTT + 4*Deviation 9

10 RTT e Timeout timeout round-trip time 10

11 Congestione 11

12 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

13 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

14 Prestazioni ideali Carico normalizzato 14 Throughput normalizzato

15 Ritardo Carico normalizzato 15

16 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 B Congestione severa 1.0 Carico normalizzato 16

17 Approcci al controllo della congestione Due approcci di larga massima: Controllo di congestione end-to-end: assenza di un feedback esplicito dalla rete congestione dedotta dalle perdite e dai ritardi osservati dal sender approccio seguito dal TCP Controllo di congestione assistito dalla rete: i router forniscono feedback agli end system singolo bit indicante congestione (SNA, DECbit, TCP/IP ECN, ATM) velocità esplicita a cui il sender dovrebbe trasmettere 17

18 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

19 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

20 Implicito (delay,scarto) policing backpressure source Choke packet Esplicito (binario,credito,velocità) destination Meccanismi per il controllo della congestione 20

21 Messa al passo di segmenti TCP Sorgente Segmenti di dati Segmenti di ACK Destinazione 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

22 Sorgente Segmenti di dati segmenti di ACK Destinazione Flusso determinato dal sistema di destinazione 22

23 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

24 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

25 Controllo di congestione 25

26 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

27 Gestione del Timeout 27

28 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

29 Gestione della Window 29

30 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

31 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

32 Slowstart 32

33 TCP Slowstart Slowstart initialize: CongWin = 1 Threshold = 8 for (ogni ACK ricevuto) CongWin++ until (perdita OR CongWin > Threshold) RTT Host A Host B one segment two segments four segments crescita esponenziale (rispetto a RTT) in window size (non così lento!) evento di perdita: timeout (Tahoe TCP) e/o tre ACK duplicati (Reno TCP) time 33

34 Congestion Avoidance 34

35 TCP Congestion Avoidance Congestion avoidance /* slow startè finita */ /* CongWin > Threshold */ Until (perdita) { ogni w ACK ricevuti: Congwin++ } Threshold = CongWin/2 CongWin = 1 1 effettua slowstart 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

36 Timeout Round-trip times 36

37 Fast retransmit e Fast recovery 37

38 Fast retransmit e fast recovery TCP sender: Un ACK duplicato è causato da un segmento perso o soltanto da un segmento fuori ordine? Se il TCP sender riceve tre ACK duplicati, assume questa come una indicazione che il segmento seguente il segmento riscontrato è stato perso TCP eseguefast retransmit di un segmento perso prima che il suo timer scada e comincia la fase di slow start (TCP Tahoe) TCP Reno (de facto TCP) impiega anche un meccanismo di fast recovery che essenzialmente salta la fase di slow start dopo una fast retransmission (la congestione dopo tutto è moderata se sono ritornati ACK multipli!!) 38

39 TCP/Reno: Big Picture cwnd TD TD ssthresh TO ssthresh ssthresh ssthresh slow start congestion avoidance congestion avoidance congestion avoidance slow start congestion avoidance Time TD: Triple duplicate acknowledgements TO: Timeout 39

40 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

41 Equità 41

42 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

43 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) R Throughput connessione 2 Linea di piena utilizzazione di banda Uguale condivisione di banda Throughput connessione 1 R 43

44 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