Transmission Control Protocol: TCP Crediti Parte delle slide seguenti sono adattate dalla versione originale di J.F Kurose and K.W. Ross (© 1996-2003 All Rights Reserved)

TCP: Generalità RFC: 793, 1122, 1323, 2018, 2581 point-to-point: un sender, un receiver byte steam affidabile e ordinato: flusso non strutturato send & receive buffer MSS: maximum segment size (1500, 536, 512 byte) dati full duplex : flusso dei dati bidirezionale sulla stessa connessione connection-oriented: handshaking (scambio di messaggi di controllo) client-server-client (a tre vie) prima dello scambio dei dati flow control: il sender non “intasa” il receiver

TCP: Struttura del segmento source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pnter checksum F S R P A U head len not used Options (variable length) URG: urgent data (generalm. non usato) conteggio dei byte (non segmenti!) ACK: ACK n. valido PSH: push data now (generalm. non usato) N. byte rcvr può accettare RST, SYN, FIN: connection estab (comandi di creaz./interr. conness.) Internet checksum (come in UDP)

TCP: Numeri di sequenza e riscontro Suddivisione dati in segmenti: “File di 500.000 byte MSS = 1.000 byte Sequence number: Numero all’interno del flusso di byte del primo byte nel segmento ACK number: “Numero di sequenza del byte successivo atteso dall’altro host Riscontri cumulativi

TCP: Numeri di sequenza e riscontro Il numero di sequenza iniziale non è = 0 per evitare segmenti passati siano utilizzati da una nuova connessione Riscontro dei dati inviati da A a B su segmento dati da B ad A (piggyback) D: Come gestisce il receiver i segmenti non in ordine? R: Le spec. TCP non impongono alcuna regola Host A Host B utente digita ‘C’ Seq=42, ACK=79, data = ‘C’ host B riscontra ricezione di ‘C’ e invia indietro ‘C’ Seq=79, ACK=43, data = ‘C’ host riscontra ricezione di ‘C’ dall’host B Seq=43, ACK=80 tempo Telnet (RFC 854) scenario

TCP: Gestione della connessione Handshake a tre vie: Step 1: client manda segmento TCP SYN al server specifica numero sequenza iniziale nessun dato Step 2: server riceve SYN e replica con un segmento SYNACK server alloca buffer specifica il sequence number del server Step 3: client riceve SYNACK, replica con segmento ACK che può contenere dati Ricordare: Sender e receiver TCP stabiliscono una “connessione” prima di scambiarsi segmenti di dati inizializzazione variabili TCP: sequence number buffer, flow control info (es. RcvWindow) client: inizia la connessione connect(sock, &server, serverlen); server: contattato dal client listen (sock, queuelen); accept (msgsock, &client, clientlen);

TCP: Gestione della connessione (cont.) Chiusura connessione: il cliente chiude la socket: close (sock); Step 1: client manda segmento FIN al server Step 2: server riceve FIN, e replica con ACK. Chiude la connessione, invia un FIN. client FIN server ACK close closed timed wait

TCP: Gestione della connessione (cont.) Step 3: client riceve un FIN, replica con ACK entra in uno stato “time wait” – permette al client di inviare l’ACK se riceve altri FIN (es. il primo ACK viene perso) Step 4: server riceve ACK. Connessione chiusa. client server closing FIN ACK closing FIN ACK timed wait closed closed

TCP: Gestione della connessione (cont.) TCP server lifecycle TCP client lifecycle

TCP: Round Trip Time (RTT) e Timeout TCP implementa un meccanismo di timeout/ritrasmissione per gestire perdite di pacchetti D: Come setta TCP il timeout? più lungo del RTT ma il RTT varia troppo corto: timeout prematuro ritrasmissioni non necessarie trppo lungo: reazione lenta alla perdita di segmenti D: Come stimare il RTT? SampleRTT: tempo trascorso tra la trasmissione di un segmento e la ricezione dell’ACK relativo ignora le ritrasmissioni SampleRTT varia, è necessario stimare un RTT “medio” si usano parecchie misurazioni recenti, non solo il SampleRTT corrente

TCP: Round Trip Time (RTT) e Timeout EstimatedRTT = (1- ) * EstimatedRTT +  * SampleRTT Media esponenziale mobile pesata (EWMA - Exponential weighted moving average) la media dei campioni passati decresce esponenzialmente valore tipico:  = 0.125 EstimatedRTT = 0,875 * EstimatedRTT + 0,125 * SampleRTT

TCP: Round Trip Time (RTT) e Timeout Settaggio del timeout EstimatedRTT più un “margine di sicurezza” ampie fluttuazioni in SampleRTT -> grandi variazioni nell’EstimatedRTT -> margine di sicurezza maggiore Prima si stima quanto il SampleRTT “devia” dall’EstimatedRTT: Quindi si setta il timeout: DevRTT = (1-) * DevRTT +  * |SampleRTT-EstimatedRTT| (tipicamente  = 0,25) TimeoutInterval = EstimatedRTT + 4*DevRTT

TCP: Esempio di stima del RTT

TCP: Trasferimento dati affidabile TCP crea un servizio rdt (reliable data transfer) sopra al servizio inaffidabile IP Perdite Errori Non in ordine Invio dei segmenti in pipeline ACK cumulativi TCP utilizza un singolo timer di ritrasmissione Ritrasmissioni sono causate da: timeout ACK duplicati Inizialmente si consideri un TCP sender semplificato: ignora gli ack duplicati ignora controllo di flusso e controllo di congestione

TCP: Eventi nel sender Ricezione dati dall’applic.: Crea segmento con sequence number Avvia il timer se non è già attivo si pensi al timer come associato al più vecchio segmento non riscontrato expiration interval: TimeOutInterval calcolato tramite EstimatedRTT e DevRTT Timeout: ritrasmetti il segmento che ha causato il timeout riavvia il timer ACK ricevuto: Se riscontra segmenti ancora non riscontrati aggiorna la sequenza di segmenti riscontrati avvia il timer se ci sono segmenti non ancora riscontrati

TCP sender (semplific.) NextSeqNum = InitialSeqNum SendBase = InitialSeqNum loop (forever) { switch(event) event: data received from application above create TCP segment with sequence number NextSeqNum if (timer currently not running) start timer pass segment to IP NextSeqNum = NextSeqNum + length(data) event: timer timeout retransmit not-yet-acknowledged segment with smallest sequence number event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) } } /* end of loop forever */ TCP sender (semplific.) Commento: SendBase-1: ultimo byte cumulativamente riscontrato Esempio: SendBase-1 = 71; y= 73, il ricevitore vuole 73+ ; y > SendBase, così i nuovi dati sono riscontrati

TCP: Scenari di ritrasmissione Host A Seq=92, 8 bytes data ACK=100 loss timeout ACK perso Host B X time Host A Host B Seq=92 timeout Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=100 ACK=120 Sendbase = 100 Seq=92, 8 bytes data SendBase = 120 Seq=92 timeout ACK=120 SendBase = 100 SendBase = 120 time timeout prematuro

TCP: Scenari di ritrasmissione (cont.) Host A Seq=92, 8 bytes data ACK=100 loss timeout ACK cumulativo Host B X Seq=100, 20 bytes data ACK=120 time Raddoppio timeout: Quando il timeout scade: ritrasmetti il segmento con num. sequenza più piccolo raddoppia il timeout precedente Quando l’ACK arriva: setta il timeout in funzione di EstimatedRTT e DevRTT Forma limitata di controllo congestione SendBase = 120

TCP: Generazione ACK [RFC 1122, RFC 2581] Evento al receiver arrivo segmento in ordine, nessun buco, dati precedenti già riscontrati un altro segmento attende ACK num. sequenza più alto, buco rilevato arrivo segmento che copre buco parzialmente o totalmente Azione del receiver ACK ritardato. Aspetta fino a 500 ms per il prossimo segmento. Se non arriva, invia ACK invia immediatamente singolo ACK cumulativo invia ACK duplicato, indicando sequence number del prossimo byte atteso invia immediatamente ACK se il segmento inizia all’estremità inferiore del buco

Ritrasmissione veloce Time-out spesso relativamente lungo ritardo considerevole prima della ritrasmissione del pacchetto perso Segmenti persi rilevati via ACK duplicati Se un segmento non arriva il receiver invia un ACK duplicato per il segmento precedente Il sender spesso invia molti segmenti back-to-back Se il segmento è perso ci saranno probabilmente molti ACK duplicati Se il sender riceve 3 ACK per gli stessi dati presuppone che il segmento successivo ai dati riscontrati è andato perso: ritrasmissione veloce: ritrasmetti il segmento prima che il timer scada

Algoritmo di ritrasmissione veloce event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of duplicate ACKs received for y if (count of duplicate ACKs received for y = 3) { resend segment with sequence number y un ACK duplicato per un segmento già riscontrato ritrasmissione veloce

Controllo di Flusso del TCP il sender non saturerà il buffer del receiver trasmettendo troppo e troppo velocemente flow control il lato ricevente di una connessione TCP ha un buffer di ricezione: il processo applic. può essere lento a leggere dal buffer bisogna uguagliare la velocità di invio dei dati a quella di svuotamento del buffer RcvBuffer = dimensione TCP Receive Buffer RcvWindow = dimens. spazio disponibile nel buffer

Controllo di Flusso del TCP: come funziona Rcvr informa dello spazio disponibile includendo il valore di RcvWindow nei segmenti al sender Sender limita invio dati non riscontrati al valore RcvWindow garantisce che il buffer del receiver non si saturi LastByteSent – LastByteAcked ≤ RcvWindow (Ipotesi: receiver cancella segmenti non in ordine) spazio disponibile nel buffer RcvWindow = RcvBuffer -[LastByteRcvd - LastByteRead]

Controllo della Congestione del TCP Controllo end-end (nessun feedback dalla rete) La congestion window, CongWin, è dinamica, funzione della congestione di rete percepita Il sender limita la trasmissione in funzione della congestione percepita: LastByteSent-LastByteAcked  min(CongWin, RcvWindow) Congwin Ritmo approssimativo di invio dei dati: CongWin/RTT throughput = w * MSS RTT byte/s

Controllo della Congestione del TCP Come percepisce il sender la congestione? evento di perdita = timeout o 3 ACK duplicati Il senderTCP riduce il ritmo trasmissivo (CongWin) dopo l’evento di perdita Algoritmo di controllo della congestione di TCP Tre meccanismi Partenza lenta (slow start) Reazione differenziata a eventi di perdita Incremento additivo, decremento moltiplicativo (AIMD)

Controllo della Congestione del TCP “Esplorazione” della banda utilizzabile: idealmente: trasmettere quanto più velocemente possibile (CongWin più grande possibile) se non ci sono perdite aumenta Congwin fino alla perdita (congestione) perdita: decrementa Congwin, poi comincia a esplorare (aumentare) di nuovo Due “fasi” slow start prevenzione congestione variabili importanti: CongWin Threshold: definisce la soglia tra la fase “slow start” e quella di “prevenzione della congestione”

TCP Slowstart Slowstart algorithm initialize: Congwin = 1 Host A Slowstart algorithm Host B one segment initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > Threshold) RTT two segments four segments crescita esponenziale (per RTT) della dimensione della finestra (non così lenta!) evento di perdita: timeout (Tahoe TCP) e/o 3 ACK duplicati (Reno TCP) time

Prevenzione della congestione: Tahoe TCP Tahoe Congestion avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every RTT (roughly): Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart Cong. avoid. Slow start loss event = timeout= 3 duplicate ACKs

Prevenzione della congestione: Reno 3 ACK duplicati: alcuni segmenti riescono ad attraversare la rete non “esagerare” riducendo la finestra a 1 segmento come in Tahoe riduci la CongWin di metà ripresa veloce (fast recovery) Timeout come Tahoe TCP TCP Reno Congestion avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every RTT (roughly): Congwin++ } threshold = Congwin/2 If (loss detected by timeout) { Congwin = 1 perform slowstart } If (loss detected by 3 duplicate ACKs) Congwin = Congwin/2

TCP Reno versus TCP Tahoe 2 4 6 8 10 12 14 1 3 5 7 9 11 13 15 Transmission round congestion window size (segments) Series1 Series2 threshold TCP Tahoe Reno

TCP: AIMD Decremento moltiplicativo: Riduci CongWin di metà dopo un evento di perdita (3 dupl. ACKs) Incremento additivo: Aumenta CongWin di 1 segmento ogni RTT in assenza di perdite (esplorazione) Connessione TCP a regime

Ricapitolando: TCP Congestion Control Quando CongWin è sotto Threshold, il sender è in fase di slow-start, la finestra cresce esponenzialmente. Quando CongWin è sopra Threshold, il sender è in fase di congestion-avoidance, la finestra cresce linearmente. Quando avviene un triplo duplicate ACK, Threshold è posta a CongWin/2 and CongWin è posta a Threshold. Quando avviene un timeout, Threshold è posta a CongWin/2 e CongWin è posta a 1 MSS.

TCP Fairness Fairness goal: se K sessioniTCP condividono lo stesso link “collo di bottiglia” di banda R, ognuno dovrebbe avere una banda media di R/K TCP connection 1 bottleneck router capacity R TCP connection 2

Perchè TCP è fair? Due sessioni in competizione: Un incremento additivo da una retta a 45° quando il throghput cresce (entrambe connessioni aumentano di 1 MSS per RTT) Un decremento moltiplicativo diminuisce il throughput proporzionalmente R equal bandwidth share loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 2 throughput loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput R