Riferimenti I protocolli TCP e UDP TCP Illustrated, vol. 1 (Richard Stevens) RFC 1122/1123 (R. T. Braden) Requirements for Internet Hosts (1989) RFC 2001 (R. Stevens) TCP Slow Start, algorithms (1997) RFC 2581 (Allman, Paxson, Stevens) TCP Congestion Control (1999) Principi Fondamentali Sorgente TCP TCP (Transmission Control Protocol ) è un protocollo di livello 4 (Transport) E connection-oriented Offre un servizio affidabile Opera in modalità full-duplex Suddivide i dati dell applicazione in segmenti Usa un protocollo a finestra (selective repeat) per regolare la velocità trasmissiva controllo di flusso controllo di congestione attiva dei timer quando invia i segmenti: segmenti non confermati allo scadere del timer (timeout - RTO) provocano ritrasmissioni esegue un obbigatorio su header e dati Ricevitore TCP Invia ACK di ricezione di segmenti corretti e in sequenza scarta segmenti duplicati ed invia ACK dell ultimo segmento ricevuto in sequenza scarta segmenti con errati, senza inviare ACK riordina segmenti fuori sequenza annuncia alla sorgente lo spazio libero nel buffer di ricezione 20 bytes 32 bit
Source port Number Destin. Port Number Source port Number Destin. Port Number Identificano le applicazioni che stanno inviando e ricevendo. Combinati con i rispettivi indirizzi IP, identificano in modo univoco una connessione Identifica il byte nello stream di dati che il primo byte del segmento rappresenta Source port Number Destin. Port Number Source port Number Destin. Port Number Identifica il byte nello stream di dati che il primo byte del segmento rappresenta Ogni lato della connessione procede con numeri di sequenza diversi e indipendenti Numero di sequenza più 1 dell ultimo byte di dati ricevuto correttamente Lunghezza dell header in parole di 32 bit Numero di sequenza più 1 dell ultimo byte di dati ricevuto correttamente Valido solo con ACK flag settato HLEN Resv. flags Receiver window
Riservato per usi futuri Sei bit di flag, uno o più possono essere settati insieme: URG: urgent pointer valid ACK: ack number is valid PSH: pass data quickly to app RST: reset connection SYN: synchronize seq. no. FIN: no more data to send Numero di bytes, a partire da quello nel campo di ACK, che il ricevitore è disposto ad accettare (max 65535, a meno che sia usata la scaling option per finestre grandi) Checksum obbligatorio su header e dati, più pseudo-header che include indirizzi IP e tipo di protocollo TCP options (MSS) Puntatore a dati urgenti nel campo dati (es. ctrl-c in una sessione telnet). Offset rispetto al num. di seq. Valido solo se flag URG è settato Campo tra header e dati Opzione più usata è l MSS (Maximum Segment Size), inviato nel segmento iniziale di una connessione Non è negoziato, ogni lato annuncia l MSS che si aspetta di ricevere Se non presente, si usa il default a 536 bytes Al massimo: MSS = MTU - 40 bytes
Apertura di connessione (three-way handshake) Chiusura di connessione (TCP half-close) source (client) destination (server) source (client) destination (server) time SYN / ISN c <MSS c > SYN / ISN s ACK / ISN c +1 ACK / ISN s +1 <MSS s > three-way handshake il client esegue un open attivo, mentre il server esegue un open passivo ISN (initial sequence number) è dato da un contatore, incrementato ogni 8 µsec un SYN consuma un numero di sequenza close da applicazione EOF a livelli alti FIN / Seq. Numb. c ACK (Seq.Numb. C +1) FIN / Seq. Numb. s ACK (Seq. Numb. s +1) EOF a livelli alti close da applicazione Controlli di flusso e congestione Il controllo di flusso Il throughput di connessioni TCP lunghe e persistenti è regolato attraverso due forme di controllo: controllo di flusso: evita che un host veloce saturi un ricevitore lento controllo di congestione: evita che un host aggressivo saturi la rete trasmettendo sempre alla velocità massima consentita dal ricevitore Usato per grossi volumi di dati e lunghi trasferimenti (modalità bulk) TCP impiega un controllo di flusso end-to-end basato su protocollo a finestra Durante una connessione, ogni ricevitore impone la dimensione massima della finestra del trasmettitore quando invia un ack La dimensione imposta indica lo spazio libero attuale in ricezione Sliding Window Sliding Window Numero seq. di segmento Numero seq. di segmento finestra offerta (pubblicizzata dal ricev.) finestra usabile 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 segmenti spediti, ack ricevuto segmenti spediti, ack da ricevere segmenti da spedire segmenti spediti, ack ricevuto segmenti spediti, ack da ricevere segmenti da spedire segmenti non ancora spedibili
Dinamica della Sliding Window Il controllo di congestione chiude restringe la finestra si chiude quando un nuovo segmento viene TX la finestra trasla a destra se viene ricevuto un Ack di un nuovo segmento la finestra si apre se il controllo di congestione lo permette e se non è raggiunta la finestra imposta dal ricevitore, W max apre/trasla la finestra si restringe se un host limita ulteriormente la ricezione (tecnica non usata e sconsigliata ) Se l ampiezza della finestra collassa ho una zero window, che arresta la trasmissione Inizialmente (<1988) era previsto che TCP avesse come unico controllo la finestra imposta dal RX Questa soluzione funziona se i due host sono sulla stessa LAN, ma se ho router intermedi e linee lente posso avere congestione Il risultato è una pesante riduzione del throughput delle connessioni TCP, costrette a frequenti ritrasmissioni Gli elementi del controllo di congestione 4 algoritmi, introdotti in fasi successive: Slow Start Congestion Avoidance Fast Retransmit Fast Recovery Oltre alla finestra imposta dal RX, il TX si autoimpone una congestion window (cwnd), regolata dai 4 algoritmi sopra Algoritmo di Slow Start Principio: il rate di trasmissione di nuovi segmenti dovrebbe uniformarsi al rate di ricezione degli ACK Secondo l algoritmo Slow Start, il TX può inviare fino a n segmenti TCP con n = min (swnd, cwnd) All inizio della connessione, si ha cwnd = 1 segmento Ad ogni ACK ricevuto, cwnd = cwnd + 1 La crescita risultante è (quasi) esponenziale Il Congestion Avoidance Algoritmo di Congestion Avoidance Il Congestion Avoidance collabora con lo Slow Start La connessione TCP opera in due modalità: la modalità slow start e la modalità congestion avoidance Due indicatori di congestione in rete: scadenza di un timeout su un ack o ricezione di ack duplicati Se TX rileva congestione in rete nella modalità congestion avoidance (scade timeout di un ack), viene retrocesso in slow start SLOW START CONGESTION AVOIDANCE 1) cwnd = 1 segmento ssthresh = finestra imposta dal ricevitore, W max 2) cwnd = cwnd + 1 ad ogni ack finché cwnd > ssthresh (goto 3) se ho un RTO: ssthresh = min(cwnd,w max )/2 cwnd = 1 3) cwnd = cwnd + 1/ cwnd ad ogni ack finché ho un RTO: ssthresh = min(cwnd,swnd)/2 (in bytes) cwnd = 1 goto 2)
Osservazioni - 1 Osservazioni - 2 la crescita della congestion window dipende dalla procedura di delayed ack Gli ack sono solitamente inviati ogni 2 pacchetti ricevuti: la crescita della finestra avviene a velocità dimezzata L invio immediato dell ack si ha solamente se è ricevuto un segmento fuori sequenza, nel qual caso viene ackato l ultimo segmento ricevuto in sequenza. Questo origina ack duplicati Il termine Slow Start può essere fuorviante Quello che si intende è trasmissione più lenta di quando è avvenuta la congestione In realtà, in Slow Start, il rate di trasmissione continua a crescere finché non si entra in Congestion Avoidance Fast Retransmit e Fast Recovery Gli algoritmi (1) Ulteriore modifica all algoritmo di Congestion Avoidance proposta nel 1990 Permette la ritrasmissione immediata di segmenti singoli andati perduti (fast retransmit) e per evitare la retrocessione a Slow Start quando ad essere perso è un solo segmento (fast recovery) Osservo gli ack duplicati: se sono uno o due, può essere solo uno scambio di segmenti se sono tre o più è una forte indicazione di segmento perso Se vengono ricevuti tre ack duplicati, ritrasmetto il segmento mancante senza aspettare la scadenza del timeout (fast retransmit). Inoltre, eseguo il congestion avoidance e non lo slow start (fast recovery) Gli algoritmi (2) Il calcolo del timeout (1) Quando ricevo il 3 ack duplicato consecutivo: ssthresh = min(cwnd,swnd)/2 (in bytes) ritrasmetto il segmento mancante cwnd=ssthresh+3*segsize (in bytes) Ad ogni ack duplicato successivo: cwnd=cwnd+1 Quando arriva l ack del segmento mancante: cwnd=ssthresh Il valore del timeout di trasmissione è essenziale per il funzionamento di TCP In particolare, è funzione del round-trip time della connessione, che varia per il traffico e la congestione delle code dei router occorre quindi una stima del round-trip time per determinare il timeout da impostare
Il calcolo del timeout (2) Problemi nel calcolo del timeout Per ogni segmento calcolo la differenza di tempo M tra il suo invio e la RX di un ack La stima del round-trip time (RTT) viene mediata da un coefficiente α: RTT=αRTT+(1-α)M Il timeout (RTO)viene calcolato come: RTO=β*RTT (β>1) Se uso campioni relativi a segmenti ritrasmessi, la misura non è più accurata Algoritmo di Karn: non ricalcolo l RTO finché non ricevo un ack di un segmento non ritrasmesso Inoltre la varianza del ritardo può causare fluttuazioni della stima del RTT uso formule più complesse per la stima del RTT, che tengono conto dell errore medio nella stima Silly Window Syndrome Problema con ricevitori lenti o trasmettitori che inviano piccoli blocchi di dati alla volta Se il buffer del RX si riempie, il RX accetta blocchi di dati sempre più esigui, forzando dimensioni ridotte della finestra: questo crea problemi di overhead (rapporto header/dati) Se il TX invia tinygrams (es. sessione telnet) occorre far intervenire l algoritmo di Nagle Dal lato ricevitore: Silly Window Syndrome avoidance comunico la nuova finestra di RX solo quando questa è pari al MSS, o a metà del buffer di RX uso il delayed acknowledgment Dal lato trasmettitore: uso algoritmo di Nagle Dinamiche di connessioni TCP Flussi brevi Algoritmo di Nagle (rfc 896) Utilizzata per trasferimenti di esigue quantità di dati (esempio: pressione tasto su terminale remoto) Il teoria, ogni tasto premuto genera un pacchetto TCP in un datagram IP dedicato (20B+20B+1B=41B). In realtà, se c è echo locale, i pacchetti sarebbero 4: tasto+ ack+echo+ack Posso usare piggybacking del primo ack su pacchetto di echo, e risparmio l invio un pacchetto TCP Delayed ack : gli ack vengono solitamente ritardati di 200 ms nella speranza di fare piggybacking I datagram contenenti un solo carattere (tinygrams) possono accrescere la congestione di WAN già sature L algoritmo di Nagle prevede che un host non possa avere in rete più di un tinygram senza ack Fino all arrivo dell ack, tutti i caratteri successivi sono raccolti in un unico segmento, spedito dopo l ack Questa procedura permette di ridurre il numero tinygrams sulla rete ed è autoregolante: più veloci tornano gli ack (segno di poca congestione) e più segmenti invio sulla rete
Caratteristiche Il protocollo UDP UDP (User Datagram Protocol ) permette alle applicazioni di un host l invio di datagram ad altre applicazioni di un host remoto UDP fornisce un servizio di livello 4, ma: connectionless (pacchetti fuori sequenza) non affidabile (pacchetti persi) senza controllo di flusso (saturazione del ricevitore) ma allora è come il protocollo IP??? UDP non è IP! Formato del pacchetto UDP UDP usa le capacità di IP di instradare i pacchetti, non sarebbe in grado di farlo UDP è in grado di discriminare tra più applicazioni che risiedono sullo stesso host (attraverso la porta ), IP consegna solo il datagram all host UDP esegue (opzionale) su header e dati, IP solo su header Un applicazione che usa UDP deve prendersi carico di risolvere i problemi di affidabilità, inclusa la perdita di pacchetti, la duplicazione, la risequenzializzazione... 0 15 16 31 UDP Source Port UDP Destination Port UDP Message Length UDP Checksum (opt.) DATA 32 bit