Protocollo TCP. politiche di trasmissione e di controllo della congestione

Transcript

1 Protocollo TCP politiche di trasmissione e di controllo della congestione

2 TCPDUMP 1) A.1341 > B.80: S : (0) win 8192 <mss 1460> 2) B.80 > A.1341: S : (0) ack win <mss 536> 3) A.1341 > B.80:. ack win ) A.1341 > B.80: P : (176) ack win ) B.80 > A.1341: P : (228) ack win ) A.1341 > B.80:. ack win ) B.80 > A.1341: P : (323) ack win ) A.1341 > B.80:. ack win ) B.80 > A.1341: F : (0) ack win ) A.1341 > B.80:. ack win

3 Politiche di trasmissione L'idea di fondo è la seguente: la dimensione delle finestre scorrevoli non è strettamente legata agli ACK, ma viene continuamente adattata mediante un dialogo fra destinazione e sorgente. Il controllo di flusso end-to-end è quindi gestito usando la finestra a dimensioni variabili quando il destinatario invia un ACK di conferma, annuncia anche quanti ulteriori byte possono essere spediti a partire dal byte riscontrato ( (finestra suggerita) Campo WindowSize dell intestazione TCP 3

4 Esempio: buffer negoziato di 4K 4

5 Buffer, ecc. Se la finestra ha dimensioni zero il Mittente si blocca, con due eccezioni: URGENT DATA: ad esempio per uccidere il processo che gira sulla macchina ricevente richieste di reinvio dell'ultimo ack spedito (per evitare il deadlock se l ack si è perso). I peer sono liberi di trasmettere quando vogliono,, ad esempio quando la finestra è piena e l overhead di pacchetto è minimo 5

6 problemi Il Mittente (S) non deve inviare tutti i dati immediatamente Il Ricevente (R) non deve né rispondere subito con un ACK né consegnare immediatamente Cosa succede se: l applicazione Mittente genera un carattere alla volta? l applicazione Ricevente consuma un carattere alla volta? 6

7 Ottimizzazione di flussi con piccoli pacchetti Una connessione Telnet manda un carattere alla volta e non fa un echo locale del carattere, che deve essere rimandato dal server questa situazione richiede nel caso peggiore (TCP/IP) un segmento di per mandare il byte un segmento di 40 byte di ack un segmento di WindowSize di 40 byte un segmento con il carattere di ritorno (echo) di byte in totale 162 byte per ogni byte di dati, 4 segmenti inviati se si ritarda l ack e il WindowSize può darsi che queste informazioni possano essere aggiunte al pacchetto di echo 7

8 algoritmo di Nagle mandare il primo byte immediatamente bufferizzare gli altri fino a quando non arriva un ack e inviare il buffer così riempito inviare il buffer comunque, se contiene MSS bytes Se si usa questo algoritmo con protocolli tipo X-Windows l arrivo dei byte a burst può creare problemi il mouse si muove a scatti. 8

9 Silly window syndrome (finestra sciocca) Se il ricevente legge un byte alla volta e il mittente deve inviare molti bytes, la finestra è sempre piena e si instaura una comunicazione di un byte alla volta algoritmo di Clark il ricevente non manda WindowSize fino a quando non può ricevere almeno un segmento di dimensione negoziata all inizio della connessione (MSS) o il buffer è mezzo vuoto 9

10 Controllo della congestione per ogni segmento inviato viene settato un timer di ritrasmissione bisogna distinguere tra due casi ACK è in ritardo per fluttuazioni casuali del traffico la rete è congestionata e il segmento inviato è stato perso Il protocollo TCP assume che, se gli ack non tornano in tempo, ciò sia dovuto a congestione della subnet piuttosto che a errori di trasmissione le moderne linee di trasmissione sono molto affidabili quindi: scatta il timeout? => probabile congestione 10

11 qual è l approccio di TCP Gestire e controllare la congestione una volta che si è verificata,, non cercare di evitare la congestione In effetti TCP aumenta sempre il carico sulla rete nel tentativo di trovare il punto di congestione e quindi retrocede da questo punto Quindi: TCP ha bisogno di creare perdite di dati per determinare la banda disponibile della connessione 11

12 approccio... Questo meccanismo di gestione della congestione è stato introdotto nel 1988 da Van Jacobson, otto anni dopo che il protocollo TCP/IP divenne operativo Nel periodo immediatamente precedente Internet aveva sofferto da collasso da congestione gli host inviavano i loro pacchetti in rete tanto rapidamente quanto la finestra suggerita lo consentiva, causando congestione nei router che scartavano i pacchetti in sovrannumero, gli host di conseguenza andavano in timeout e dovevavno ritrasmettere i loro pacchetti, auymentando percià la congestione. 12

13 Timer management TCP usa parecchi timer diversi timer di ritrasmissione (RTO) timer di persistenza timer keepalive timer per chiusura connessione 13

14 Timeout management algoritmo di Jacobsen A livello transport c è molta variabilità, quindi è difficile scegliere un valore ottimale per i timeout bisogna spesso variare il valore dei timeout Si mantiene la stima del round-trip RTT misurando continuamente il round-trip RTT = α RTT + (1- α) ) NuovaMisura dove α vale solitamente 7/8 Il timeout è calcolato come RTT + 4 D dove D è la deviazione media: D = α D + (1- α) ) RTT - NuovaMisura Intuitivamente quando c è molta variabilità il timeout sale attenzione: il valore è arrotondato granularità ms 14

15 Algoritmo di Karn Quando arriva un Ack di un segmento ritrasmesso,, il mittente può interpretarlo in due modi: Si tratta dell ACK relativo alla prima trasmissione del segmento. In questo caso, l RTT è semplicemente più lungo del previsto ma riflette l effettive condizioni di rete. Si tratta dell ACK relativo alla seconda ritrasmissione. Non potendo riconoscere le due situazioni è meglio ignorare l informazione. il valore di RTT potrebbe diventare molto errato i segmenti ritrasmessi non sono mai usati per cambiare il timeout, invece nel caso di una ritrasmissione lo si raddoppia ad ogni errore (exponential back-off) 15

16 Altri timer Persistence timer: per richiedere le dimensioni della finestra se non cambia da molto evita il possibile deadlock Keepalive timer: per testare una connessione che è stata inattiva per lungo tempo il timer forza l invio di un pacchetto che chiede al peer se è ancora disponibile timer chiusura connessione 2 * MSL (tempo massimo di vita di un pacchetto) 16

17 Controllo della Congestione due tipi di problemi: (post 1988) scarsità di buffer a destinazione congestione della subnet ciascuno dei problemi viene gestito da una specifica finestra mantenuta dal mittente: la finestra del ricevente [ W ] la congestion window [ cwnd ], che rappresenta quanto il mittente può spedire senza causare congestione Il mittente si regola sulla più piccola delle due Due algoritmi combinati assieme: Slow Start congestion avoidance Additive Increase / Multiplicative Decrease 17

18 alla partenza Slow Start In fase di apertura della connessione, la scelta della finestra è critica, perché non si hanno informazioni sullo stato della rete Allora si attua il meccanismo di Slow Start inizializza cwnd = 1 segmento per ogni ACK ricevuto si aumenta cwnd di uno Se tutti i segmente vengono riscontrati, la finestra raddoppia di volta in volta e quindi in realtà la crescita è esponenziale 18

19 esempio La dimensione della finestra di congestione (cwnd( cwnd) cresce molto rapidamente la crescita può essere in effetti esponenziale: si incrementa cwnd di 1 per ogni ACK ricevuto cwnd=1 cwnd=2 cwnd=4 19

20 in dettaglio Al setup della connessione, il mittente inizializza cwnd := MSS bytes ( 1 segmento ) quindi invia un segmento quando l ack è ricevuto cwnd := cwnd + MSS quindi invia 2 segmenti per ogni ack ricevuto cwnd := cwnd + MSS invia i segmenti, secondo la dimensione della finestra la crescita di cwnd aumenta finchè: si verifica un timeout ( (vedi slide AI/MD) si raggiunge la dimensione di W 20

21 Slow Start Sequence Plot... Sequence No Window doubles every round Segment ack Time 21

22 Congestion avoidance AI/MD Come reagire in caso di congestione? Dopo un timeout,, entra in gioco un terzo parametro, soglia per la partenza lenta (ssthresh),, inizializzato a 64K sstresh := cwnd / 2 cwnd := 1MSS si riparte con Slow Start, incrementando cwnd di 1 per ogni ACK ricevuto, fino a che cwnd= ssthresh per cwnd >= ssthresh il valore di cwnd cresce linearmente di 1 MSS per ogni RTT circa in pratica per ogni ACK si incrementa cwnd di (MSS/N), dove N è il numero di segmenti della finestra, quindi: incremento = MSS / N = MSS / (cwnd( / MSS) = = MSS * MSS / cwnd se non si verificano più timeout, cwnd crescerà fino alla dimensione di W e rimarrà costante - a meno di altri timeout o di variazioni di W 22

23 Congestion Avoidance Sequence Plot Sequence No Window grows by 1 every round Time 23

24 Slow Start e Congestion Avoidance (1) Servono due variabili: finestra di congestione ( (cwnd) valore soglia ( (ssthresh) Inizializzazione cwnd = MSS bytes (1 segmento) ssthresh = 64K bytes Finestra del Mittente: MIN (Finestra Ricevente, cwnd) 24

25 Slow Start e Congestion Avoidance (2) cwnd = MSS bytes ssthresh = 64K bytes NoTimeout: If cwnd <= ssthresh then /* do Slow Start: exponential */ Each time an Ack is received: cwnd = cwnd + MSS else /* cwnd > ssthresh */ /* do congestion avoidance: linear */ Each time an Ack is received: cwnd = cwnd + MSS * MSS / cwnd endif Timeout : ssthresh = cwnd / 2 cwnd = 1 25

26 esempio segmenti di dimensione 1 Kbyte, threshold a 32 Kbyte e congestion window arrivata a 40 Kbyte 26

27 Slow Start/Congestion Avoidance cwnd = 1 Cwnd (in segments) Assume that ssthresh = 8 ssthresh cwnd = 2 cwnd = 4 cwnd = 8 cwnd = 9 Roundtrip times cwnd = 10 27

28 plottando.. cwnd Timeout Congestion Avoidance Slow Start Time 28

29 Slow Start / Congestion Avoidance considerazioni la versione iniziale di TCP (pre 1988) dopo il setup della connessione inviava tanti dati quanti richiesti con il valore W i router a volte non riuscivano a consumare il picco di pacchetti quanto buffer space è disponibile nei router? Slow start evita il picco perché dilaziona l invio dei pacchetti ma... può portare a inefficienze...??? 29

30 problemi nel calcolo di RTO i calcoli di RTO sono effettuati in modo arrotondato usando timer a grana grossa (anche 500 ms) la stima di RTT non è molto accurata in alcuni test si è verificato che mediamente possono intercorrere fino a 1100 ms da quando TCP invia un segmento (che risulta poi perso) a quando TCP va in timeout e rimanda il segmento ci sarebbero voluti invece meno di 300ms, se si fosse usato un clock più accurato 30

31 fast retransmission in pratica il valore di RTO è molto maggiore del reale RTT le ritrasmissioni basate sullo scadere di questo timer possono essere molto lente il meccanismo Fast retransmission sfrutta il fatto che TCP sempre invia un ACK per l ultimo segmento che ha ricevuto con successo in ordine corretto ACK duplicati (dup( duplicate ACK) ) di uno stesso segmento stanno ad indicare un segmento mancante, forse perduto 31

32 quindi... R riceve: 5, 6, 7, 8, 10, 11, 12, 13 (nb. # #99?)? e ACKs: 6, 8, 8, 8, 8, 8 [4 dupacks] I Dupack forniscono un suggerimento al Mittente che il pacchetto #9 è stato probabilmente perso e che 4 pacchetti sono arrivati dopo quello #8. per escludere la possibilità che il segmento sia solo in ritardo per un qualche motivo, si aspetta finchè non si ricevono 3 ACK duplicati per lo stesso segmento in una fast retransmission, questo fatto è interpretato come una reale perdita per il segmento e quindi il segmento è ritrasmesso prima del timeout 32

33 Fast Retransmit Sequence No X Retransmission Duplicate Acks Time 33

34 Multiple Losses Sequence No X X X Now what? (... see TCP Versions) Retransmission Duplicate Acks Time 34

35 fast recovery Ma anche nel caso di una fast retransmission, la dimensione della finestra di congestione è stata ridotta per alleviare la congestione gli ACK ricevuti però mostrano che c è comunque del traffico sulla rete e che la congestione non può quindi essere così severa come nel caso dello scadere di RTO il nuovo meccanismo, fast recovery, evita che il canale di comunicazione ( pipe ) si svuoti dopo la fase di fast retransmit si evita quindi la fase di SlowStart per ri-caricare il canale dopo la perdita di un singolo pacchetto Fast Recovery opera assumendo che ogni dupack ricevuto rappresenti un singolo pacchetto che ha lasciato la pipe dalla parte del ricevente 35

36 algoritmo di fast recovery la finestra non viene riportata a 1, ma, dopo la ricezione del terzo dupack: ssthresh = cwnd / 2 ritrasmettere il segmento mancante (fast retransmit) cwnd = ssthresh + 3*MSS ( (sono stati ricevuti in effetti tre segmenti) se si ricevono ancora ACK relativi allo stesso segmento: cwnd = cwnd + 1*MSS trasmettere un nuovo pacchetto, se possibile quando infine si riceve l ACK di un segmento non ritrasmesso (ACK che allo stesso tempo riguarda tutti i segmenti mancanti e posteriori) allora: cwnd = ssthresh 36

37 Fast Retransmit and Fast Recovery cwnd Slow Start Congestion Avoidance Time Retransmit after 3 duplicated acks prevent expensive timeouts No need to slow start again At steady state, cwnd oscillates around the optimal window size. 37

38 automa per le politiche di trasmissione Le lettere indicano gli eventi, i numeri le modifiche da apportare ai parametri del protocollo A: cwnd >= sstresh; B: ACK; C: Timeout; D: 3 DUPACK; E: più ACK ricevuti; F: DUPACK 1: cwnd=cwnd+1; 2: sstresh=cwnd/2 ; cwnd=1; 3: sstresh=cwnd/2 ; cwnd=sstresh+3; 4: cwnd=sstresh 38

39 Selective Acknowledgment (SACK) è una opzione che viene negoziata all apertura della connessione abilita la notifica al mittente di tutti i segmenti, anche non consecutivi,, che sono stati ricevuti il ricevente può notificare che ha ricevuto più di un segmento fuori sequenza il Mittente ricevendo un SACK sa esattamente quali segmenti sono stati consegnati può ritrasmettere solo i segmenti che ricadono nei buchi dello spazio dei numeri di sequenza indicato nel SACK Il Mittente può evitare delays e ritrasmissioni non necessarie, ottenendo un throughput migliore SACK offre quindi un miglioramento delle prestazioni proprio quando in un RTT si perda più di un segmento 39

40 SACK: esempio The SACK option as defined in RFC 2018 is as follows: Kind=5 Length Left Edge of 1st Block Right Edge of 1st Block /... / Left Edge of nth Block Right Edge of nth Block The Selective Acknowledgement (SACK) option in the TCP header contains a number of SACK blocks where each block specifies the left and right edge of a block of data received at the TCP receiver. In particular, a block represents a contiguous sequence space of data received and queued at the receiver, where the "left edge" of the block is the first sequence number of the block, and the "right edge is the sequence number immediately following the last sequence number of the block. 40