DNS: Domain Name System

DNS: Domain Name System People: molti identificativi: o # CF, nome, # passaporto Host e router in Internet: o o indirizzo IP (32 bit) usato per indirizzare datagrams nome, e.g., pianeta.di.unito.it usato dagli esseri umani Domanda: corrispondenza tra indirizzo IP e nome? Domain Name System: database distribuito implementato con una gerarchia di name server protocollo di livello application host, router, e name servers comunicano per risolvere nomi (traduzione indirizzo/nome) o nota: funzione chiave in Internet, implementata come protocollo a livello application o complessità nella edge network 2: Livello Application 43

Servizi offerti dal DNS Traduzione di indirizzi mnemonico -> IP Host aliasing o indirizzi mnemonici complicati possono avere alias più semplici Mail server aliasing Distribuzione di carico o o web server replicati su host con stesso indirizzo mnemonico (e.g., cnn.com) ma diversi indirizzi IP rotazione degli indirizzi nelle risposte (l ordine determina chi contattare per primo da parte del client HTTP) 2: Livello Application 44

DNS name servers Perché non centralizzare il DNS? punto unico di guasto volume di traffico database centralizzato distante mantenimento non scala! nessun server ha tutte le corrispondenze nome-indirizzo IP name server locali: o o ogni ISP o azienda ha dei name server locali (default) la query DNS di un host è innanzitutto diretta al name server locale name server autoritativo: o o per un host: memorizza il nome e l indirizzo IP di quell host può eseguire la traduzione nome/indirizzo per il nome di quell host 2: Livello Application 45

DNS: Root name servers contattati dai name server locali che non sanno risolvere un nome root name server: o o o contatta il name server autoritativo se la corrispondenza per il nome non è conosciuta ottiene la corrispondenza e NASA Mt View, CA f Internet Software C. Palo Alto, CA restituisce la corrispondenza al name server locale a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA k RIPE London i NORDUnet Stockholm m WIDE Tokyo b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA 13 root name server nel mondo 2: Livello Application 46

Semplice esempio DNS root name server l host surf.eurecom.fr vuole l indirizzo IP di gaia.cs.umass.edu 1. contatta il suo server DNS locale, dns.eurecom.fr 2. dns.eurecom.fr contatta il root name server, se necessario 3. il root name server contatta il name server autoritativo, dns.umass.edu, se necessario local name server dns.eurecom.fr 1 2 6 host richiedente surf.eurecom.fr 5 3 4 name server autorititivo dns.umass.edu gaia.cs.umass.edu 2: Livello Application 47

Esempio DNS root name server Root name server: può non conoscere il name server autoritativo può conoscere un name server intermedio : chi contattare per trovare il name server autoritativo local name server dns.eurecom.fr 1 2 8 host richiedente surf.eurecom.fr 7 3 6 name server intermedio dns.umass.edu 4 5 name server autoritativo dns.cs.umass.edu gaia.cs.umass.edu 2: Livello Application 48

DNS: query iterate root name server query ricorsive: scarica il peso della risoluzione del nome sul name server contattato carico pesante? query iterate: il server contattato risponde con il nome del server da contattare Non conosco questo nome ma chiedi a questo server local name server dns.eurecom.fr 1 2 8 host richiedente surf.eurecom.fr 3 4 7 query iterate name server intermedio dns.umass.edu 5 6 name server autoritativo dns.cs.umass.edu gaia.cs.umass.edu 2: Livello Application 49

DNS: caching e aggiornamento record una volta che un (qualunque) name server impara una corrispondenza, la mette in una cache o gli elementi della cache vanno in timeout (scompaiono) dopo qualche tempo meccanismo di aggiornamento/notifica sotto progetto del IETF o RFC 2136 o http://www.ietf.org/html.charters/dnsind-charter.html 2: Livello Application 50

DNS record DNS: database distribuito che memorizza record di risorse, resource records (RR) Type=A o o Type=NS o o formato RR: (name, value, type, ttl) name è un hostname value è un indirizzo IP name è un dominio (e.g. foo.com) value è un indirizzo IP di un name server autoritativo per questo dominio Type=CNAME o o name è un alias di un nome canonico (quello vero) www.ibm.com è in realtà servereast.backup2.ibm.com value è il nome canonico Type=MX o value è il nome del mailserver associato a name 2: Livello Application 51

DNS record Se un name server è autoritativo per un host allora conterrà un record con Type=A per quell host Un name server non autoritativo può contenere un record con Type=A (caching) Se un name server non è autoritativo per un host allora conterrà un record con Type=NS per il dominio che include l host; conterrà anche un record con Type=A e indirizzo IP per il campo Value del record con Type=NS o o (umass.edu, dns.umass.edu, NS) (dns.umass.edu,128.119.40.111,a) 2: Livello Application 52

Protocollo DNS: i messaggi Protocollo DNS : messaggi di query e reply, entrambi con lo stesso formato di messaggio header del messaggio identificazione: # di 16 bit per le query, e il reply alla query usa lo stesso # flag: o query o reply o ricorsione desiderata o ricorsione disponibile o reply è autoritativo 2: Livello Application 53

Protocollo DNS: i messaggi Nome, campi tipo per una query RR in risposta ad una query record per server autoritativi informazioni utili aggiuntive che possono essere usate (e.g., RR con Type=A per alias mail server) 2: Livello Application 54

Parte 2: sommario Completato lo studio delle applicazioni di rete! requisiti di servizio delle applicazioni: o affidabilità, larghezza di banda, ritardo paradigma client-server Modelli di servizio di trasporto in Internet o o connection-oriented, affidabile: TCP non affidabile, datagram: UDP protocolli specifici: o o o o http ftp smtp, pop3 dns programmazione con socket o o implementazione di un client/server usando socket tcp, udp 2: Livello Application 72

Parte 2: sommario Più importante: imparato qualcosa sui protocolli tipico scambio di messaggi request/reply: o o il client richiede servizi o informazioni il server risponde inviando dati e codici di stato formati dei messaggi: o o header (intestazioni): i campi danno informazioni sui dati dati: informazioni che vengono comunicate messaggi di controllo vs. dati o in-based, out-of-band centralizzato vs. decentralizzato stateless vs. con stato trasferimento di messaggi affidabile vs. non affidabile complessità ai bordi della rete sicurezza: auetenticazione 2: Livello Application 73

Parte 3: livello transport Obiettivi: comprendere i principi alla base dei servizi a livello di trasporto: multiplexing/demultiplex ing trasferimento dati affidabile controllo di flusso controllo di congestione realizzazione in Internet Panoramica: servizi del livello di trasporto multiplexing/demultiplexing trasporto connectionless: UDP principi di trasferimento dati affidabile trasporto connection-oriented: TCP trasferimento affidabile controllo di flusso gestione delle connessioni principi del controllo di congestione controllo di congestione in TCP 3: Livello Transport 1

Protocolli e servizi di Trasporto fornire la comunicazione logica tra processi (applicazioni di rete) in esecuzione su host diversi i protocolli di trasporto sono eseguiti sugli host (endsystem) servizi di livello transport vs servizi di livello network: livello network: trsferimento dati tra host (end-system) livello trasporto: trasferimento dati tra processi si affida ai sevizi di livello network application transport network data link physical network data link physical trasporto end-to-end logico network data link physical network data link physical network data link physical network data link physical application transport network data link physical 3: Livello Transport 2

Protocollo di livello di trasporto Servizi di trasporto in Internet: trasporto affidabile, in ordine, unicast (1-to-1): (TCP) congestione controllo di flusso setup della connessione trasporto non affidabile ( best-effort ), non ordinato, unicast o multicast (1 to-m): UDP servizi non disponibili: real-time larghezza di banda garantita multicast affidabile application transport network data link physical network data link physical trasporto end-to-end logico network data link physical network data link physical network data link physical network data link physical application transport network data link physical 3: Livello Transport 3

Analogia umana (1) Due abitazioni (Italia, Australia) abitate da fratelli (10 in Italia e 10 in Australia) cugini degli altri 10 Ognuno scrive agli altri 10 una lettera in buste separate recapitate dalle Poste (Italiana ed Australiana) Ogni settimana 100 lettere partono da una abitazione verso l altra In ogni abitazione c è un responsabile (Teo e Tea) che, ogni settimana, raccoglie e distribuisce le lettere (in partenza e in arrivo). Se in partenza le passa al postino che passa dall abitazione ogni giorno dal quale raccoglie quelle in arrivo 3: Livello Transport 4

Analogia umana (2) Le Poste offrono, in questo esempio, la comunicazione logica tra le due abitazioni Teo e Teo offrono la comunicazione logica tra cugini (abitanti nella stessa casa) Dal punto di vista dei cugini, Teo e Tea sono il servizio postale anche se ne sono solo una parte (quella finale) 3: Livello Transport 5

Analogia umana (3) Abitazioni = Host (End System) Cugini = Processi su un Host Lettere in busta = Messaggi delle Applicazioni Servizio postale = Protocolli di livello network Teo e Tea = Protocolli di livello Transport 3: Livello Transport 6

Analogia umana (4) Teo e Tea svolgono il loro compito nelle abitazioni e non si curano della gestione delle lettere nei vari uffici postali nel cammino dall Italia all Australia e viceversa Analogamente, i protocolli di livello Transport sono parte degli host (end system) e non dei router (e gateway) Il servizio postale non conosce il contenuto delle lettere o distingue tra tipi di mittente o destinatario Analogamente, i router della core network non discriminano i pacchetti che stanno instradando 3: Livello Transport 7

Analogia umana (5) Teo e Tea a volte sono sostituiti da Beo e Bea che, essendo più piccoli, non raccolgono e smistano frequentemente le lettere o, a volte, ne smarriscono alcune Analogamente, i servizi del livello Transport offerti ai processi possono differire all interno di un host (TCP o UDP) I servizi offerti da Teo e Tea sono vincolati ai servizi che il servizio postale offre, e.g., garanzia del recapito entro tre giorni Analogamente, i servizi del livello transport sono limitati e condizionati dal modello di servizio del livello network, e.g., garanzie sul ritardo o ampiezza di banda 3: Livello Transport 8

Multiplexing/demultiplexing IP fornisce comunicazione logica tra due host usando l indirizzo IP!! Ricordate: segmento unità dati scambiata tra entità del livello di trasporto alias TPDU: transport protocol data unit header segmento segmento dati del livello application Ht M Hn segmento P1 M application transport network P3 Demultiplexing: smistare i segmenti ricevuti ai giusti processi del livello application in esecuzione sugli host ricevente M M application transport network P4 M P2 application transport network 3: Livello Transport 9

Multiplexing/demultiplexing analogia umana? Multiplexing: raccolta dei messaggi da diversi processi del livello application, aggiunta di un header ai dati (usato successivamente per il demultiplexing) multiplexing/demultiplexing: si basa sul numero di porta del mittente (source) e del destinatario (destination), e sugli indirizzi IP numero di porta di source (mittente) e destination (ricevente) in ogni segmento ricordate: ci sono i numeri di porta well-known usati da applicazioni specifiche (http, smtp ) (da 0 a 1023) 32 bits source port # dest port # altri campi dell header dati applicazione (messaggio) formato del segmento TCP/UDP 3: Livello Transport 10

Multiplexing/demultiplexing: esempi host A source port: x dest. port: 23 server B client Web host C source port:23 dest. port: x uso della porta: applicazione telnet Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 client Web host A Source IP: A Dest IP: B source port: x dest. port: 80 Web server B uso della porta: Web server 3: Livello Transport 11

UDP: User Datagram Protocol [RFC 768] protocollo di livello trasporto in Internet servizio best effort, i segmenti UDP possono essere: persi recapitati non in ordine all applicazione connectionless: senza handshaking tra mittente UDP e ricevitore UDP ogni segmento UDP viene gestito indipendentemente dagli altri Perché esiste UDP? senza creazione di una connessione (che può aggiungere ritardo) semplice: senza stato della connessione nel mittente e nel ricevitore piccolo header del segmento senza controllo di congestione: UDP può spedire dati alla velocità che desidera 3: Livello Transport 12

UDP: User Datagram Protocol usato spesso per applicazioni di streaming multimedia tolleranti alle perdite dipendenti dalla velocità (rate sensitive) altri usi di UDP(perché?): DNS SNMP trasferimento affidabile con UDP: si aggiunge l affidabilità al livello di applicazione recupero dall errore dipendente dall applicazione! Lunghezza, in bytes del segmento UDP, incluso l header 32 bits source port # dest port # lunghezza Dati applicazione (messaggio) checksum formato del segmento UDP 3: Livello Transport 13

UDP checksum Obiettivo: riconoscimento errori (e.g., bit invertiti) nei segmenti trasmessi Mittente: tratta il contenuto dei segmenti come sequenze di interi di 16 bit checksum: somma (in complemento ad 1) del contenuto dei segmenti il mittente scrive il valore del checksum nel campo checksum del segmento UDP Ricevente: calcola il checksum del segmento ricevuto controlla se il checksum calcolato è uguale al valore del campo checksum del segmento: NO riconoscimento errore SI nessun errore riconosciuto. Forse c è comunque un errore? Vediamo dopo. 3: Livello Transport 14

Principi del trasferimento dati affidabile importante nel livello applicazione, trasporto e data link importante argomento di networking! le caratteristiche di un canale non affidabile determineranno la complessità del protocollo di trasferimento affidabile di dati (rdt) 3: Livello Transport 15

Trasferimento dati affidabile : gli inizi rdt_send(): invocata dall alto, (e.g., dall applicazione). Passaggio dei dati da recapitare al ricevitore al livello superiore deliver_data(): invocata da rdt per recapitare i dati al livello superiore lato mittente lato ricevente udt_send(): invocata da rdt, per trasferire pacchetti su un canale non affidabile ad un ricevitore rdt_rcv():invocata quando il pacchetto arriva sul lato del ricevitore del canale 3: Livello Transport 16

Trasferimento dati affidabile : gli inizi Cosa faremo: sviluppiamo in maniera incrementale (con miglioramenti successivi) il lato mittente e ricevente del protocollo per trasferimento di dati affidabile (rdt) consideriamo solo trasferimenti dati unidirezionali anche se le informazioni di controllo possono viaggiare in entrambe le direzioni! usiamo una macchina a stati finiti (FSM) per specificare (descrivere) mittente e destinatario stato: quando ci si trova in questo stato il prossimo stato è univocamente determinato dal prossimo evento evento che causa una transizione di stato azioni effettuate in seguito a transizione di stato stato 1 evento azione stato 2 3: Livello Transport 17

Rdt1.0: trasferimento affidabile su un canale affidabile canale sottostante perfettamente affidabile nessun errore sui bit trasmessi nessuna perdita di pacchetti FSM separati per mittente e ricevente: mittente spedisce dati sul canale sottostante ricevente riceve dati dal canale sottostante 3: Livello Transport 18

Rdt2.0: canale con errori sui bit IPOTESI: pacchetti ricevuti in ordine il canale sottostante può invertire i bit in un pacchetto ricordate: il checksum di UDP rileva gli errori sui bit la domanda: come si può recuperare un errore?: acknowledgements (ACK) (conferma di ricezione): il ricevitore comunica esplicitamente al mittente di aver ricevuto correttamente il pacchetto negative acknowledgements (NAK): il ricevitore comunica esplicitamente al mittente di aver ricevuto con errori il pacchetto il mittente ritrasmette il pacchetto in seguito alla ricezione di un NAK analogie umane dell uso di ACK e NAK? nuovi meccanismi in rdt2.0 (rispetto a rdt1.0): rilevazione di errori feedback da parte del ricevente: messaggi di controllo (ACK,NAK) ricevente -> mittente ri-trasmissione 3: Livello Transport 19

rdt2.0: specifica dei FSM FSM del mittente stop and wait Il mittente spedisce un pacchetto, ed attende una risposta del ricevente FSM del ricevente 3: Livello Transport 20

rdt2.0: in azione (senza errori) FSM del mittente FSM del ricevente 3: Livello Transport 21

rdt2.0: in azione (scenario con errori) FSM del mittente FSM del ricevente 3: Livello Transport 22

rdt2.0 ha un difetto fondamentale! Che succede se ACK/NAK vengono rovinati (errori in trasmissione)? il mittente non sa cosa è successo al ricevente! non può solo ritrasmettere: possibile duplicazione Cosa fare? ACK/NAK del mittente e ACK/NAK del ricevente? Cosa succede se ACK/NAK del mittente vengono rovinati? ritrasmettere, ma ciò potrebbe causare la ritrasmissione di pacchetti ricevuti correttamente! Gestione dei duplicati: il mittente aggiunge un numero di sequenza ad ogni pacchetto il mittente ri-trasmette il pacchetto corrente se l ACK/NAK contiene errori il ricevente scarta (non recapita ai livelli superiori) pacchetti duplicati 3: Livello Transport 23

rdt2.1: mittente, gestisce ACK/NAK distorti 3: Livello Transport 24

rdt2.1: ricevente, gestisce ACK/NAK distorti 3: Livello Transport 25

rdt2.1: discussione Mittente: numero di sequenze aggiunto ai pacchetti solo due numeri di sequenza (0,1) vanno bene. Perché? si deve controllare se gli ACK/NAK ricevuti sono rovinati gli FSM hanno il doppio degli stati lo stato deve ricordare se il pacchetto corrente ha numero di sequenza 0 o 1 Ricevente: deve controllare se il pacchetto ricevuto è duplicato lo stato indica se 0 o 1 è il numero di sequenza atteso nota: il ricevente non può sapere se il suo ultimo ACK/NAK è stato ricevuto dal mittente senza errori 3: Livello Transport 26

rdt2.2: un protocollo senza NAK stesse funzionalità di rdt2.1, usando solo ACK invece di un NAK, il ricevente spedisce un ACK per l ultimo pacchetto ricevuto correttamente il ricevitore deve includere esplicitamente il numero di sequenza del pacchetto confermato dall ACK ACK duplicati al mittente danno origine alla stessa azione di un NAK: ritrasmissione del pacchetto corrente! FSM del mittente 3: Livello Transport 27

rdt3.0: canali con errori e perdite Nuove ipotesi: il canale sottostante può anche perdere pacchetti (dati o ACK) checksum, numeri di sequenza, ACK, ritrasmissioni aiutano ma non abbastanza Domanda: come gestire le perdite? rilevare le perdite azioni per gestire la perdita Approccio: il mittente attende un ACK per un tempo ragionevole ri-trasmette se non ha ricevuto ACK entro questo tempo se il pacchetto (o l ACK) sono solo in ritardo (non persi) : la ri-trasmissione sarà duplicata, ma l uso dei numeri di sequenza gestisce questo caso il ricevitore deve specificare il numero di sequenza del pacchetto per il quale spedisce l ACK è necessario un countdown timer 3: Livello Transport 28

rdt3.0 mittente 3: Livello Transport 29

rdt3.0 in azione 3: Livello Transport 30

rdt3.0 in azione 3: Livello Transport 31

Prestazioni di rdt3.0 rdt3.0 funziona ma fornisce pessime prestazioni esempio: canale a 1 Gbps link, 15 ms propagation delay, pacchetti da 1KB: T transmit = 8kb/pkt 10**9 b/sec = 8 microsec frazione di tempo Utilizzazione = U = = 8 microsec durante la quale il 30.016 msec mittente è impegnato a trasmettere = 0.00015 un pacchetto da 1KB ogni 30 msec -> 33kB/sec su 1 Gbps il protocollo di rete limita l uso delle risorse fisiche! 3: Livello Transport 32

Protocolli Pipelined Pipelining: il mittente permette che ci siano pacchetti in transito per i quali ancora non è stato ricevuto un ACK i possibili valori dei numeri di sequenza devono aumentare buffering al mittente e/o ricevente Due forme generiche di protocolli pipelined: go-back- N, selective repeat 3: Livello Transport 33

Go-Back-N Mittente: numero di sequenza di k bit nell header del pacchetto finestra di, fino a, N pacchetti consecutivi non ancora con ACK ACK(n): fornise un ACK di tutti i pacchetti i cui numeri di sequenza vanno fino ad n incluso cumulative ACK timer per ogni pacchetto in transito timeout(n): ri-trasmette il pacchetto con numero di sequenza n e tutti quelli con numero di sequenza maggiore nella finestra 3: Livello Transport 34

GBN: FSM esteso del mittente 3: Livello Transport 35

GBN: FSM esteso del ricevente semplice ricevente: manda un ACK: manda sempre un ACK per pacchetti con il numero di sequenza più alto ricevuti in ordine e correttamente può generare ACK duplicati deve solo ricordare expectedseqnum pacchetti non in ordine: elimina (non bufferizza) -> ricevente senza buffering! ACK per pacchetto con il numero di sequenza più alto ricevuto in ordine 3: Livello Transport 36

GBN in azione 3: Livello Transport 37

Selective Repeat il ricevente manda un ACK individuale per tutti i pacchetti correttamente ricevuti bufferizza pacchetti, se necessario, per il recapito finale in ordine al livello superiore il mittente ri-spedisce solo i pacchetti per i quali non ha ricevuto un ACK timer del mittente per ogni pacchetto senza ACK finestra del mittente N numeri di sequenza consecutivi limita il numero di sequenza di pacchetti spediti e non ancora con ACK 3: Livello Transport 38

Selective repeat: finestre mittente e ricevente 3: Livello Transport 39

Selective repeat mittente data dal livello superiore: se il prossimo numero di sequenza disponibile è nella finestra spedisce il pacchetto timeout(n): ri-spedisce il pacchetto, riinizializza il timer ACK(n) in [sendbase,sendbase+n]: marca il pacchetto n come ricevuto se n è il più piccolo pacchetto senza ACK, avanza la base della finestra al prossimo numero di sequenza di un pacchetto senza ACK ricevente pacchetto n in [rcvbase, rcvbase+n-1] spedisce ACK(n) non in ordine: bufferizza in ordine: recapita (recapita anche pacchetti in ordine bufferizzati), avanza la finestra al prossimo pacchetto non ancora ricevuto pacchetto n in [rcvbase- N,rcvbase-1] ACK(n) altrimenti: ignora pacchetto 3: Livello Transport 40

Selective repeat in azione 3: Livello Transport 41

socket door TCP: Panoramica RFC: 793, 1122, 1323, 2018, 2581 punto-punto: 1 mittente, 1 ricevente Flusso di byte ordinato ed affidabile: pipelined: Il controllo di flusso e di congestione determinano una dimensione di finestra Buffer di spedizione e ricezione application writes data TCP send buffer segment application reads data TCP receive buffer socket door Dati full-duplex: flusso dati bi-direzionale nella stessa connessione MSS: maximum segment size connection-oriented: handshaking (scambio di messaggi di controllo) inizializzazione dello stato del mittente e del ricevitore prima dello scambio dati controllo di flusso: il mittente non sovraccaricherà il ricevente 3: Livello Transport 42

Struttura del segmento TCP URG: urgent data (in genere non usato) ACK: numero ACK valido PSH: push data now (in genere non usato) RST, SYN, FIN: inizio connessione (comandi setup, teardown) Internet checksum (come in UDP) 32 bits source port # dest port # head len sequence number acknowledgement number not used UA P R S F checksum rcvr window size ptr urgent data Options (variable length) application data (variable length) contano in termini di byte di dati (non segmenti!) numero di bytes che il ricevente desidera accettare 3: Livello Transport 43

Numeri di sequenza e ACK in TCP Numeri di sequenza: numero del primo byte di un segmento del flusso di byte ACK: numero di sequenza del prossimo byte atteso dall altra parte ACK cumulativo Domanda: come sono gestiti dal ricevente segmenti non in ordine? Risposta: la specifica di TCP non lo stabilisce scelta dell implementazione 3: Livello Transport 44

Numeri di sequenza e ACK in TCP file di 500000 byte MSS di 1000 byte 3: Livello Transport 45

Numeri di sequenza e ACK in TCP Host A Host B Spedizione secondo segmento Seq=1000, ACK=79, data = Seq=79, ACK=2000, data = l host manda un ACK per confermare la ricezione di del segmento e comunica il # di sequenza del prossimo byte atteso tempo 3: Livello Transport 46

Numeri di sequenza e ACK in TCP Host A Host B Spedizione quarto segmento con perdita del terzo Seq=4000, ACK=79, data = Seq=79, ACK=2000, data = l host manda un ACK per il # di sequenza del prossimo byte atteso tempo 3: Livello Transport 47

Numeri di sequenza e ACK in TCP Host A Host B Utente digita C l host manda un ACK per la ricezione dell echo C Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 l host manda un ACK per confermare la ricezione di C, Manda indietro un echo per C semplice scenario telnet tempo 3: Livello Transport 48

TCP: trasferimento dati affidabile evento: dato ricevuto dall applicazione (livello superiore) crea e spedisci il segmento wait for event attendi evento evento: timeout del timer per il segmento con numero di sequenza y ri-trasmetti il segmento mittente semplificato assumendo che: trasferimento dati one way senza controllo di flusso e congestione evento: ACK ricevuto con numero di ACK y elaborazione dell ACK 3: Livello Transport 49

TCP: trasferimento dati affidabile Mittente TCP semplificato 00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 02 03 loop (forever) { 04 switch(event) 05 event: data received from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compute new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y > sendbase) { /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers < y 17 sendbase = y 18 } 19 else { /* a duplicate ACK for already ACKed segment */ 20 increment number of duplicate ACKs received for y 21 if (number of duplicate ACKS received for y == 3) { 22 /* TCP fast retransmit */ 23 resend segment with sequence number y 24 restart timer for segment y 25 } 26 } /* end of loop forever */ 3: Livello Transport 50

Generazione di ACK in TCP [RFC 1122, 2581] Evento arrivo di un segmento in ordine, senza buchi nella sequenza, tutto il resto già con ACK arrivo di un segmento in ordine, senza buchi nella sequenza, un ACK ritardato è pendente arrivo di un segmento non in ordine, # di sequenza > di quello atteso rilevazione di un buco arrivo di un segmento che parzialmente o completamente riempie il buco Azione del ricevente TCP ACK ritardato. Attende fino a 500ms il prossimo segmento. Se non c è un prossimo segmento manda un ACK spedisce immediatamente un solo ACK cumulativo spedisce un ACK duplicato che indica il # di sequenza del prossimo byte atteso spedisce una ACK immediatamente se il segmento inizia al limite sinistro del buco 3: Livello Transport 51

TCP: scenari di ri-trasmissione Host A Host B Host A Host B Seq=92, 8 bytes data Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=100 ACK=120 ACK=100 X timeout Seq=100 timeout Seq=92 timeout perdita Seq=92, 8 bytes data Seq=92, 8 bytes data ACK=120 ACK=100 tempo scenario per ACK perso tempo timeout prematuro, ACK cumulativi 3: Livello Transport 52

Controllo di flusso in TCP controllo di flusso il mittente non sovraccaricherà il buffer del ricevente trasmettendo troppo troppo velocemente RcvBuffer = dimensione del buffer di ricezione TCP RcvWindow = ammontare di spazio disponibile nel buffer ricevente: informa esplicitamente il mittente dell ammontare di spazio disponibile nel buffer (dinamicamente variabile) RcvWindow campo nel segmento TCP mittente: mantiene l ammontare di dati trasmessi ancora senza ACK minore del valore più recentemente ricevuto di RcvWindow buffer di ricezione 3: Livello Transport 53

Round Trip Time e Timeout in TCP Domanda: come si determina il valore del timeout in TCP? più alto del RTT nota: RTT è variabile troppo piccolo: timeout prematuro ritrasmissioni non necessarie troppo alto: reazione lenta alla perdita di segmenti Domanda: come stimare il RTT? SampleRTT: tempo misurato dalla trasmissione del segmento fino alla ricezione dell ACK si ignorano le ritrasmissioni, e segmenti con ACK cumulativi SampleRTT è variabile, vogliamo una stima migliore del RTT si usano diverse recenti misurazioni non solo il SampleRTT correntemente disponibile 3: Livello Transport 54

Round Trip Time e Timeout in TCP EstimatedRTT = (1-x)*EstimatedRTT + x*samplertt Exponential weighted moving average l influenza di un campione decresce esponenzialmente valori tipici di x: 0.1 Determinare il timeout EstimtedRTT più margine di sicurezza grandi variazioni di EstimatedRTT -> grande margine di sicurezza Timeout = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x* SampleRTT-EstimatedRTT 3: Livello Transport 55

Gestione della connessione in TCP Ricordate: mittente e ricevente TCP stabiliscono una connessione prima dello scambio di segmenti di dati inizializzazione di variabili TCP: numeri di sequenza buffer, informazioni per il controllo di flusso (e.g. RcvWindow) client: iniziatore della connessione Socket clientsocket = new Socket("hostname","port number"); server: contattato dal client Socket connectionsocket = welcomesocket.accept(); Three way handshake: Passo 1: l host del client spedisce un segmento di controllo TCP (SYN=1) al server specifica il # di sequenza iniziale direzione client -> server Passo 2: l host del server riceve il SYN, risponde con un segmento di controllo SYNACK è un ACK per il SYN alloca i buffer specifica il numero di sequenza iniziale in direzione server-> client Passo 3: l host del client riceve il SYNACK, risponde con un segmento di controllo con il campo SYN=0 è un ACK per il SYN alloca i buffer 3: Livello Transport 56

Three way handshake: esempio 3: Livello Transport 57

Gestione della connessione in TCP Chiusura della connessione: client server il client chiude il socket: clientsocket.close(); chiusura FIN Passo 1: l host del client spedisce un segmento di controllo FIN al server ACK FIN chiusura Passo 2: il server riceve il FIN e risponde con un ACK. Chiude la connessione e spedisce un FIN. attesa ACK chiusa chiusa 3: Livello Transport 58

Gestione della connessione in TCP Passo 3: il client riceve il FIN, risponde con un ACK. Entra in una attesa risponderà con un ACK al FIN ricevuto Step 4: il server, riceve l ACK. Connessione chiusa. chiusura client FIN ACK FIN server chiusura attesa ACK chiusa chiusa 3: Livello Transport 59

Gestione della connessione in TCP ciclo di vita di un server TCP ciclo di vita di un client TCP 3: Livello Transport 60

Principi del controllo di congestione Congestione: informalmente: troppe sorgenti spediscono troppi dati troppo velocemente perché la rete possa gestirli diverso dal controllo di flusso! manifestazioni: pacchetti persi (overflow dei buffer nei routers) grandi ritardi (accodamento nei buffer dei routers) 3: Livello Transport 61

Approcci per il controllo di congestione Due grandi approcci: Controllo della congestione End-end: nessun feedback esplicito dalla rete la congestione si inferisce dall osservazione da parte degli host delle perdite e dei ritardi approccio di TCP Controllo di congestione con l aiuto della rete: i routers forniscono feedback agli host un bit che indica congestione (SNA, DECbit, TCP/IP ECN, ATM) indicazione esplicita della velocità alla quale un mittente dovrebbe trasmettere 3: Livello Transport 62

Controllo di congestion in TCP controllo end-end (senza assistenza della rete) velocità di trasmissione limitata dalla dimensione della finestra di congestione sui segmenti, Congwin: Congwin w segmenti, ognuno di MSS bytes spediti in un RTT: throughput = w * MSS RTT Bytes/sec 3: Livello Transport 63

Controllo di congestion in TCP sondaggio della larghezza di banda usabile: idealmente: trasmettere il più velocemente possibile (Congwin il più grande possibile) senza perdite incrementare Congwin fino a quando si hanno perdite (congestione) perdite: decrementare Congwin, quindi iniziare a sondare (incrementare) ancora due fasi slow start congestion avoidance variabili importanti: Congwin threshold: definisce una soglia tra la fase di slow start e di congestion avoidance 3: Livello Transport 64

TCP Slowstart Algoritmo di Slowstart inizio: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) RTT Host A Host B 1 segmento 2 segmenti 4 segmenti incremento esponenziale (per RTT) della dimensione della finestra (non così slow!) evento di perdita: timeout (Tahoe TCP) e/o tre ACK duplicati (Reno TCP) tempo 3: Livello Transport 65

TCP Congestion Avoidance Congestion avoidance /* slowstart è terminato */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart 3: Livello Transport 66

TCP congestion avoidance: AIMD AIMD: additive increase, multiplicative decrease incremento della dimensione della finestra di 1 ogni RTT decremento della dimensione della finestra di un fattore 2 per un evento di perdita TCP Fairness Obiettivo: se N connessioni TCP condividono lo stesso canale collo di bottiglia ognuna dovrebbe ottenere 1/N della capacità del canale connessione TCP 1 connessione TCP 2 router collo di bottiglia con canale a capacità R 3: Livello Transport 67

Parte 3: Sommario principi dietro i servizi del livello di trasporto: multiplexing/demultiplexing trasferimento affidabile controllo di flusso controllo di congestione implementazione in Internet UDP TCP Prossima puntata: lasciamo la edge network (livello application e transport) ci tuffiamo nella core network 3: Livello Transport 68