Livello Trasporto TCP UDP ICMP Transport Layer 3

Livello Trasporto TCP, UDP, ICMP Transport Layer 3 -1

Il livello di trasporto r Strato di interfaccia con il livello rete r Livello rete: un canale di comunicazione molto particolare 1. Inaffidabile r I pacchetti possono morire, principalmente per tre possibili motivi: r Congestione della rete, congestione della destinazione, corruzione dei pacchetti 2. Ciò che parte non arriva sempre nello stesso ordine Transport Layer 3 -2

Principali funzioni disponibili a liv. rete r Send(ip 1, ip 2, data[]) r Data[] Receive() r Connect(), Disconnect() Transport Layer 3 -3

UDP Risolve solo i problemi di corruzione dei pacchetti, e vi da la possibilità di differenziare il traffico per numero di porta. DNS usa UDP. Transport Layer 3 -4

UDP checksum Transport Layer 3 -5

Checksum r Consente di rilevare eventuali corruzioni «spontanee» dei dati trasmessi r Assolutamente inutile in caso di manomissioni volontarie Transport Layer 3 -6

Transport Layer 3 -7

ICMP r E’ un protocollo senza numero di porta r I suoi pacchetti vengono intercettati e processati prima di essere smistati a un socket r Ping fa uso di ICMP, per misurare il round trip time, ma anche, in teoria, per controllare altri parametri di TCP. ICMP è un protocollo di servizio r I pacchetti ICMP contengono un codice messaggio, una checksum ed eventuali dati. Transport Layer 3 -8

Come è connesso TCP/UDP/ICMP allo strato applicazione r Sullo strato applicazione ci sono funzioni di libreria per aprire, chiudere, scrivere e leggere da socket r Sul livello trasporto c’è una libreria del sistema operativo (detta STACK TCP/IP) che si occupa di sbucciare e smistare i messaggi in base ai numeri di porta e al protocollo utilizzato. Transport Layer 3 -9

Comunicazione TCP: Passo 1 r Due interlocutori, messi in comunicazione con un canale inaffidabile (i pacchetti possono sparire o arrivare corrotti, o addirittura in ritardo) Transport Layer 3 -10

Transport Layer 3 -11

Implementazione. Stop & Wait r Obiettivo: implementare un canale affidabile e sequenziale su un canale non affidabile r Prima soluzione: protocollo stop & wait m Conferma di ogni pacchetto m La mancata conferma viene rilevata tramite time-out m Numeri di sequenza m Inefficiente Transport Layer 3 -12

Stop & Wait in azione http: //www. cs. stir. ac. uk/~kjt/software/comms/jasper. html Transport Layer 3 -13

Altri scenari N. B. Problema del pacchetto vagabondo Transport Layer 3 -14

Performance di stop & wait r Brutte notizie: r esempio: Banda 1 Gbps, 30 ms RTT, pacchetti da 1 KB (L): Ttrasmiss = m m m L (in bit) B = 8 kb/pkt = 8 microsec 10**9 b/sec U : % utilizzo – frazione di tempo in cui viene utilizzata la connessione 1 KB ogni 30 msec -> 33 k. B/sec effettivi contro 1 Gbps potenziali! Il protocollo limita l’uso delle risorse a disposizione Transport Layer 3 -15

Da dove deriva la formula (demo) sender receiver Trasmissione del primo bit, t = 0 Trasmissione dell’ultimo bit, t = L / B RTT Il primo bit arriva L’ultimo pacchetto arriva, Invio ACK (assumiamo sia di dim trascurabile) ACK arriva, parte il prossimo pacchetto al tempo t = RTT + L / B Transport Layer 3 -16

Comunicazione TCP: passo 2 r Protocolli a finestra scorrevole r Go Back N, Selective Repeat r Finestra dinamica r Esempio sul sito del libro di testo: m http: //media. pearsoncmg. com/aw/aw_kurose_n etwork_2/applets/go-back-n. html m http: //www. cs. stir. ac. uk/~kjt/software/comms /jasper/SWP 5. html Transport Layer 3 -17

Protocolli pipeline (a finestra scorrevole) Pipelining: ci possono essere più pacchetti “in volo”, ancora da essere confermati m m Più complesso Gestione dei buffer sofisticata r Due forme di protocolli sliding window: go-Back-N, selective repeat Transport Layer 3 -18

Pipelining: %utilizzo migliore sender receiver Trasmissione primo bit, t = 0 Trasmissione ultimo bit, t = L/R RTT Arriva ACK(1) mando il pacchetto successivo t = RTT + L / R Arriva il primo bit, primo pacchetto Ultimo bit arriva, mando ACK(1) Ultimo bit 2 do pacchetto arriva, ACK(2) Ultimo bit 3° pacchetto arriva, mando ACK(3) Utilizzo triplicato Transport Layer 3 -19

Go-Back-N (demo) Sender: r Numeri di sequenza a k bit r “finistra” di N pacchetti, pacchetti non confermati possibili r ACK(n): “il prossimo pacchetto che aspetto è il numero n” Possono arrivare ACK duplicati r C’è un timer per ogni pacchetto “in volo” r timeout(n): ritrasmette il pacchetto n e anche tutti I successivi (anche se magari erano arrivati correttamente) m Transport Layer 3 -20

GBN in azione Transport Layer 3 -21

Ripetizione selettiva (demo) r I pacchetti corretti sono confermati INDIVIDUALMENTE m I pacchetti sono conservati in attesa che possano essere rilasciati in ordine r Il mittente rimanda solo I pacchetti non confermati m C’è un timer per ogni pacchetto “in volo” r Finestra del mittente m Range di numeri attivi Transport Layer 3 -22

Finestre di ricezione e invio Transport Layer 3 -23

Ripetizione selettiva sender Ci sono dati nel buffer: r Mandali se ci sono slot Timeout(n): r Rimanda il pacchetto n ACK(n) in [sendbase, sendbase+N]: r marca n come OK r Nel caso sposta la receiver pkt n in [rcvbase, rcvbase+N-1] r manda ACK(n) r Fuori ordine? Conserva r In ordine: consegna e sposta la finestra in avanti pkt n in [rcvbase-N, rcvbase-1] r ACK(n) (duplicato che non sembra confermato) altrimenti: r ignora finestra in avanti di 1 Transport Layer 3 -24

Selective repeat in azione Transport Layer 3 -25

Problemi Esempio: r Numeri di seq: 0, 1, 2, 3 r Taglia finestra=3 r I due scenari non sono distinguibili! r Il duplicato viene passato allo strato trasporto P: Bisogna riconoscere e scartare I duplicati Transport Layer 3 -26

TCP segment structure 32 bits URG: Dati urgenti (non molto usato) ACK: Questo segmento trasporta un ACK PSH: dati ad alta priorità RST, SYN, FIN: Gestione Connessione Checksum (come in UDP) source port # dest port # sequence number acknowledgement number head not UA P R S F len used checksum Receive window Urg data pnter Options (variable length) application data (variable length) valori espressi in byte (non in numero di segmento) Numero di byte che si è disposti ad accettare al massimo Transport Layer 3 -27

Numeri di Sequenza e di ACK N. seq: m ACK: Offset del primo byte nei dati Numero del prossimo byte da ricevere m ACK cumulativo L’implementatore può decidere se conservare I segmenti fuori ordine o scartarli m Differenze pratiche: numerazione in byte, pacchetto di dim. variabile, piggybacking Host B Host A L’utente Scrive “ciao” Seq=4 2, ACK = 79, da ta = ‘Ciao ’ B risponde con ’ i h ‘E ‘Ehi’, e fa ta = a d , 6 4 K= ACK fino a 46 , AC 79 Seq= Ricevuta Di ritorno per Se q=46, ACK= ‘Ehi’ 82 tempo Transport Layer 3 -28

Situazioni di ritrasmissione Host A 2, 8 by tes da t Seq=92 timeout a 100 X = ACK loss Seq=9 2, 8 by tes da ta 100 Sendbase = 100 Send. Base = 120 = ACK Send. Base = 100 time Host B Seq=9 Send. Base = 120 ACK disperso 2, 8 by tes da ta Seq= 100, 2 0 byte s data 0 10 = K 120 = C K A AC Seq=9 2, 8 by Seq=92 timeout Seq=9 timeout Host A Host B time tes da t a 20 K=1 AC Time out prematuro Transport Layer 3 -29

ACK cumulativo Host A Host B Seq=9 timeout 2, 8 by Seq=1 tes da t a =100 K C A 00, 20 bytes data X loss 120 Send. Base = 120 = ACK time ACK cumulativo Transport Layer 3 -30

TCP Connection Management TCP necessità di aprire una connessione prima di trasmettere r Bisogna inizializzare le variabili: m Numeri di sequenza m Allocare I buffer di invio e ricezione r client: colui che apre la connessione Socket client. Socket = new Socket("hostname", "port number"); r server: colui che è contattato Socket connection. Socket = welcome. Socket. accept(); Handshake a tre vie: Step 1: Il client manda un TCP SYN al server m Indica il suo numero di seq. iniziale m no dati Step 2: Il server riceve la richiesta, replica con un pacchetto SYN/ACK Specifica il suo numero di partenza m Alloca I suoi buffer (per sfortuna) Step 3: Il client riceve SYN/ACK, risponde con un ACK, che può contenere dati m Transport Layer 3 -31

Transport Layer 3 -32

TCP Connection Management (cont. ) Chiusura di una connessione: client close Il client chiude il socket: client. Socket. close(); FIN, risponde con ACK. Chiude la connessione, e manda FIN a sua volta close FIN timed wait Step 2: il server riceve FIN ACK Step 1: il client manda TCP FIN per dire che vuole chiudere server ACK closed Transport Layer 3 -33

TCP Connection Management (cont. ) Step 3: il client riceve FIN, risponde con ACK. m client closing Si mette in “timed wait” – in questo periodo risponde con ACK a ogni FIN duplicato in arrivo server FIN ACK closing FIN Fine della conversazione. Nota: ci sono piccoli timed wait Step 4: il server riceve ACK closed accorgimenti per gestire la closed chiusura contemporanea. Transport Layer 3 -34

Diagramma a stati TCP client lifecycle Transport Layer 3 -35

Diagramma a stati TCP server lifecycle Transport Layer 3 -36

Come in TCP si decide il tempo di time-out D: come impostare questo valore? r deve essere più grande di RTT, ma non troppo m ma RTT varia r troppo corto: troppi falsi time-out m inutili ritrasmissioni r troppo lungo: reazione lenta alla perdita di un segmento D: Come stimare RTT? r Sample. RTT: tempo misurato di volta in volta tra una trasmissione e la ricezione dell’ACK corrispondente m Calcolato senza considerare casi di ritrasmissione r Sample. RTT è molto variabile m è preferibile farne una media, senza usare solo il Sample. RTT corrente. Transport Layer 3 -37

Come TCP decide il tempo di timeout (2) Estimated. RTT = (1 - )*Estimated. RTT + *Sample. RTT r I vecchi campioni pesano esponenzialmente di meno, tanto più sono lontani nel tempo r Valore tipico: = 0. 125 Transport Layer 3 -38

Esempio di stima RTT: Transport Layer 3 -39

Come in TCP si decide il tempo di time-out (3) Impostare il timeout: r Estimated. RTT più un certo margine m Estimated. RTT molto fluttuante -> maggiore margine r Si stima la deviazione media tra Sample. RTT e Estimated. RTT: Dev. RTT = (1 - )*Dev. RTT + *|Sample. RTT-Estimated. RTT| (tipicamente, = 0. 25) Quindi si calcola il time-out con la formula: Timeout. Interval = Estimated. RTT + 4*Dev. RTT Transport Layer 3 -40

Controllo di flusso (demo) flow control r Ogni ricevitore ha un buffer di ricezione: Il mittente si ‘controlla’ per non affogare il destinatario r Lo svuotamento può essere più lento del flusso di arrivo Transport Layer 3 -41

Come funziona il controllo di flusso r Il ricevitore comunica (Per comodità supponiamo i segmenti fuori ordine non vengano conservati) r Spazio libero nel buffer = Rcv. Window = Rcv. Buffer-[Last. Byte. Rcvd Last. Byte. Read] lo spazio libero usando il campo Rcv. Window r Il mittente non eccede mai il numero di byte ‘in volo’ rispetto al valore di Rcv. Window m Il buffer di ricezione non andrà mai in overflow Transport Layer 3 -42

Controllo di congestione (demo-1, demo-2) r Non solo il ricevente fa da collo di bottiglia m Infrastruttura di rete potenzialmente congestionata r Idea: Aumentare la taglia della finestra progressivamente (mai oltre Rcv. Window), finchè non scade un timeout m incremento additivo: aumenta Cong. Win di 1 MSS a ogni trasmissione finchè non scade un timeout m decremento moltiplicativo: dividi Cong. Win per due dopo una perdita Andamento a dente di sega MSS = Maximum Segment Size time Transport Layer 3 -43

Avvio ad accelerazione esponenziale Transport Layer 3 -44

Controllo di congestione r Se io posso rallentare, e tu puoi rallentare, tutto il mondo può rallentare Transport Layer 3 -45

Esempio di strategia di controllo di congestione r Quando Cong. Win è sotto Threshold, allora il mittente è in slow-start mode; raddoppio continuo di Cong. Win. r Quando Cong. Win è sopra Threshold, allora il mittente è in congestion-avoidance mode; Cong. Win cresce linearmente r Quando un arriva un triple duplicate ACK, allora Threshold : = Cong. Win/2 e Cong. Win : = Threshold (Implementazione Reno). r Quando scade un timeout, Threshold : = Cong. Win/2 e Cong. Win : = 1 MSS. Transport Layer 3 -46