Trasporto affidabile (principi)

1. Di fondamentale importanza negli strati applicativi, di trasporto e di collegamento! Le caratteristiche del canale determinano la complessità del protocollo di trasporto affidabile – reliable data transfer (rdt) Trasporto affidabile (principi)

2. rdt_send():chiamata da “sopra”, (es. app.). Dati da inviare deliver_data():invocata da rdt per consegnare i dati udt_send():chiamata da rdt per trasferire i dati sul canale non affidabile rdt_rcv():chiamata quando un pacchetto arriva al lato ricezione del canale Trasferimento affidabile (generalità) Mittente (sender) Ricevente (receiver)

3. Sviluppo incrementale dei lati mittente e ricevente del protocollo affidabile (rdt) Flusso unidirezionale dei dati (per semplicità) Flusso di controllo in entrambe le direzioni! Macchina a stati finiti (FSM) per modellare mittente e ricevente Evento Stato 1 Stato 2 Azioni Generalità (2) Evento che causa una transizione Azioni corrispondenti Stato: se in questo “stato”, lo stato successivo è determinato solo da evento

4. ASSUNZIONE: Canale affidabile Nessun errore sui bit trasmessi Nessuna perdita di pacchetti FSM distinte per mittente e ricevente: Mittente invia dati nel canale Ricevente legge dati dal canale Rdt1.0: canale affidabile

5. Il canale non affidabile può “invertire” bit Si ricordi: checksum UDP serve a individuare errori sui bit Domanda: come reagire agli errori (scoperti): Acknowledgement (ACK): il ricevente comunica esplicitamente che pacchetto OK Negative acknowledgement (NAK): il ricevente comunica esplicitamente che pacchetto ha avuto errori Il mittente ritrasmette un pacchetto se riceve NAK Nuovi meccanismi in rdt2.0 (oltre rdt1.0): Individuazione di errori Riscontro del ricevente: messaggi di controllo (ACK,NAK) ricevente->mittente (ARQ) Rdt2.0: canale con errori sui bit (no perdita pacchetti)

6. rdt2.0: specifica della FSM FSM mittente FSM ricevente

7. rdt2.0 in azione (no errori) sender FSM receiver FSM

8. rdt2.0 in azione (errori) sender FSM receiver FSM

9. Cosa succede se ACK/NAK corrotti? Il mittente non sa cosa è successo al ricevente! Cosa fare? Mittente riscontra ACK/NAK del ricevente. Cosa succede se questi ACK/NAK persi? La ritrasmissione potrebbe causare il reinvio di un pacchetto correttamente consegnato! Gestione duplicati: Il mittente aggiunge numero di sequenza (sequence number) a ciascun pacchetto Mittente ritrasmette pacchetto se ACK/NAK con errori Il ricevente distrugge (non consegna) pacchetti duplicati stop and wait rdt2.0 ha un difetto (flaw) fatale! Il mittente invia un pacchetto e aspetta la risposta

10. rdt2.1:(mittente): gestione errori negli ACK/NAK

11. rdt2.1 (ricevente): gestione errori negli ACK/NAK

12. Mittente: # seq per ogni pacchetto Due # seq. (0,1 – 1 bit) sono sufficienti. Perché? Controllo: ACK/NAK ricevuto è corrotto? Numero doppio di stati Lo stato deve “memorizzare” se il pacchetto “corrente” ha # seq. 0 o 1 Ricevente: Necessità di verificare se un pacchetto ricevuto è duplicato Lo stato indica se il # seq. atteso sia 0 o 1 Ritrasmissione: stesso numero di sequenza in due pacchetti successivi Altrimenti numero di sequenza diverso Nota: il ricevente non sa se l’ultimo ACK/NAK spedito sia stato ricevuto senza errori dal mittente rdt2.1: osservazioni

13. Stesse funzionalità di rdt2.1, ma solo ACK Invece di un NAK, il ricevente invia ACK per l’ultimo pacchetto ricevuto correttamente Il ricevente deve esplicitamente includere nell’ACK # seq del pacchetto confermato ACK duplicato al mittente ha lo stesso significato di un NAK: ritrasmetti il pacchetto corrente rdt2.2: protocollo privo di NAK (NAK-free) FSM mittente !

14. Nuova assunzione: il canale può perdere pacchetti (dati o ACK) checksum, # seq., ACK, ritrasmissioni non bastano D: come trattare la perdita? Il mittente aspetta fino ad essere certoche il pacchetto sia andato perso, poi ritrasmette Svantaggi? Approccio: il mittente attende per un intervallo “ragionevole” l’arrivo di un ACK Ritrasmette se un ACK non è ricevuto entro l’intervallo Se il pacchetto (o ACK) solo ritardato (non perso): La ritrasmissione sarà un duplicato, ma l’uso di # seq gestisce ciò Il ricevente deve indicare il # seq del pacchetto riscontrato È necessario un timer rdt3.0: canale con errori e perdita

15. rdt3.0 mittente Nota: le ritrasmissioni avvengono alla frequenza del timer

16. rdt3.0 in azione

17. rdt3.0 in azione (cont.)

18. rdt3.0 funziona, ma le prestazioni non sono buone Esempio: link da 1 Gbps, ritardo prop. end-to-end 15 ms, pacchetto da 1KB: % di tempo mitt. occupato (busy) = = 0.00015 Fatt. Uso = U = 8Kb/pkt T = 8 microsec = 8 microsec trasm 10^9 b/sec 30.016 msec Prestazioni di rdt3.0 • Pacchetto da 1KB ogni 30 msec -> throughput 33kB/sec su link da 1 Gbps!!!! • Il protocollo limita l’ uso delle risorse fisiche!

19. Pipelining: il mittente invia più pacchetti, senza attendere l’acknowledgement dei pacchetti precedenti L’intervallo dei numeri di sequenza va aumentato Buffering dei pacchetti al mittente e/o ricevente Sliding window: Go-Back-N, Selective Repeat Protocolli con pipeline (pipelined)

20. Mittente: Numero di sequenza a k-bit nell’ header del pacchetto “Finestra” (window) di (max.) N, pacchetti consecutivi non confermati Go-Back-N • ACK(n): conferma tutti i pacchetti, fino a (e incluso) quello con numero di sequenza n - “ACK cumulativo” • Timer unico per il blocco di pacchetti non confermati (“in-flight”) • timeout(n): ritrasmetti il pacchetto n e tutti quelli con numero di sequenza più alto nella finestra

21. GBN: FSM estesa (mittente) Nota: timer associato alla variabile base

22. Ricevente semplice: Solo ACK: si invia sempre l’ACK per il pacchetto con numero di sequenza più alto (mod N) tra quelli correttamente ricevuti Si possono avere ACK duplicati È sufficiente memorizzare expectedseqnum al lato ricevente Pacchetti non in ordine (out-of-order): Getta (discard), nessun buffering al lato ricezione! ACK per il pacchetto con numero di sequenza più alto tra quelli ricevuti in ordine GBN: FSM estesa (ricevente)

23. GBN inazione

24. Il ricevente conferma singolarmente tutti i pacchetti correttamente ricevuti Memorizza i pacchetti ricevuti per l’invio in ordine verso gli strati superiori Il mittente ritrasmette solamente i pacchetti per cui non ha ricevuto acknowledgement Il mittente ha un timer per ogni pacchetto non confermato Finestra del mittente N numeri di sequenza consecutivi Come con Go-Back-N si limita il numero di pacchetti trasmessi e non confermati Selective Repeat

25. Selective repeat: finestre sender, receiver

26. Dati dall’alto : Se prossimo # seq. disponibile cade nella finestra invia pacchetto timeout(n): Rimanda pacchetto n, riavvia timer pacchetto n ACK(n) in [sendbase,sendbase+N]: Marca (mark) pacchetto n come ricevuto Se n = sendbase, avanza (slide) la base della finestra fino al più piccolo pacchetto non confermato Ricevente Mittente Selective repeat (cont.) n in [rcvbase, rcvbase+N-1] • invia ACK(n) • out-of-order: memorizza (buffer) • in-order: consegna tutti I pacchetti in ordine, avanza rcvbase fino al prossimo pacchetto previsto • n in [rcvbase-N,rcvbase-1]: ACK(n) Altrimenti: • Ignora

27. Selective repeat in azione

28. Esempio: # seq.: 0, 1, 2, 3 Dim. Finestra (window size)=3 Il ricevente non nota differenze tra i due casi! Erroneamente considera il pacchettoduplicato come nuovo (a) Q: che relazione tra intervallo # seq. e dimensione finestra? Selective repeat: dilemma

29. Full duplex: Flusso dati bi-direzionale sulla stessa connessione MSS: Maximum Segment Size Connection-oriented: handshaking (scambio di msg di controllo) inizializza gli stati di mitt. e ricev. prima dello scambio dei dati Controllo di flusso (flow control): Il mittente non “inonda” (flood) il ricevente Punto-punto: Un sender, un receiver Affidabile, stream di byte in ordine (in order): no “message boundaries” Pipelining: Dim. finestra dipende dal controllo di flusso e congestione di TCP Buffer invio & ricezione TCP: generalità RFCs: 793, 1122, 1323, 2018, 2581

30. 32 bit source port # dest port # sequence number acknowledgement number head len not used rcvr window size U A P R S F checksum ptr urgent data Opzioni (lunghezza variabile) Dati (lunghezza variabile) Struttura dei segmenti TCP URG: dati urgnti (di solito non usato) Si contano i byte di dati (non i segmenti!) ACK: # ACK valido PSH: push data now (di solito non usato) # byte rcvr disposto ad accettare RST, SYN, FIN: Controllo conness. (comandi di inst., abbattimento) Internet checksum (come in UDP)

31. Numeri di sequenza: Numero del primo byte presente nel segmento ACK: # seq del prossimo byte atteso dal lato remoto ACK cumulativi D.: come il ricevente tratta segmenti fuori ordine R.: TCP non specifica, dipende dall’implementazione Tempo # seq. e ACK in TCP Host B Host A L’utente digita ‘C’ Seq=42, ACK=79, data = ‘C’ host dà ACK di ricezione, trasmette ‘C’ Seq=79, ACK=43, data = ‘C’ host dà ACK di ricezione Seq=43, ACK=80 Semplice scenario telnet

32. TCP: trasferimento affidabile evento: dati da applicazione Versione semplificata del sender, assumendo: Crea, invia segmento • Trasferimento uni-direzionale • Nessun controllo di flusso e congestione wait for event evento: timeout per il segmento con # seq y Attesa evento Ritrasmetti il segmento evento: ricevuto ACK, con # ACK y Processamento ACK

33. TCP – generazione degli ACK [RFC 1122, RFC 2581] Azione del ricevente ACK ritardato. Attendi il prossimo segmento per al più 500ms. Se non arriva invia ACK Manda subito un ACK cumulativo Manda ACK duplicato, con numero sequenza del prossimo byte atteso ACK immediato se il segmento inizia all’estremità inferiore del buco Evento Arrivo segmento in ordine, nessun buco, tutti i segmenti precedeni confermati Arrivo segmento in ordine, nessun buco, un ACK ritardato in attesa Arrivo segmento fuori ordine, # seq maggiore di quello atteso, individuato buco Arrivo segmento che riempie un buco parzialmente o totalmente

34. Host A Host B Seq=92, 8 bytes data ACK=100 timeout X loss Seq=92, 8 bytes data ACK=100 Tempo Tempo Scenario 1: ACK perso TCP: possibili casi di ritrasmissione Host A Host B Seq=92, 8 bytes data Seq=100, 20 bytes data Seq=92 timeout ACK=100 ACK=120 Seq=100 timeout Seq=92, 8 bytes data ACK=120 Scenario2: timeout prematuro, ACK cumulativi

35. Ricevente: informa esplicitamente il mitt. circa lo spazio ancora disponibile nei buffer Campo RcvWindow nel segmento TCP Mittente: mantiene la quantità di dati trasmessi e non ancora confermati (unACKed), al di sotto del valore RcvWindow più recente Controllo di flusso TCP: Controllo del flusso Mitt. non riempie i buffer del ricevente inviando troppi dati troppo velocemente RcvBuffer= dim. del buffer di ricezione TCP RcvWindow = spazio disponibile (spare) nel Buffer Buffering in ricezione

36. D: come stabilire il valore di timeout? Almeno RTT nota: RTT può variare Troppo breve: timeout prematuro Ritrasmissioni superflue Troppo lungo: reazione lenta a perdita di segmenti D:come stimare il RTT? SampleRTT: tempo misurato tra invio di un segmento e arrivo dell’ACK corrispondente Si ignorano le ritrasmissioni e i segmenti confermati da ACK cumulativi SampleRTT varia rapidamente, si vuole una stima più “costante” Si usa l’ insieme delle stime più recenti e non solo l’ultimo valore di SampleRTT (EstimatedRTT) TCP: Round Trip Time e Timeout

37. Congestione: Informalmente: “troppe sorgenti mandano dati troppo velocemente perché la rete possa smaltirle” Controllo di congestione diverso dal controllo di flusso! Sintomi: Pacchetti persi (overflow nei buffer dei router) Lunghi ritardi (accodamento nei buffer dei router) Un problema di primaria importanza! Generalità sul Controllo della Congestione

38. Due mittenti, due riceventi Un router, buffer infiniti Nessuna ritrasmissione Grandi ritardi se congestione Throughput (ritmo di trasm.) massimo ottenibile Cause/costi della congestione: scenario 1

39. Un router, buffer finiti Il mittente ritrasmette i pacchetti persi Cause/costi della congestione: scenario 2

40. Senza perdita: (goodput) Ritrasmissione “perfetta” solo in caso di perdita: La ritrasmissione dei pacchetti ritardati (non persi) rende più grande di nel caso perfetto l l l > = l l l in in in out out out Cause/costi della congestione: scenario 2 “Costi” della congestione: • Più lavoro (ritrasmissioni) per un determinato rate effettivo • Ritrasmissioni superflue: il link trasporta copie multiple del pacchetto

41. Quattro mittenti Cammini con più hop (salti) Timeout/ritrasmissione Cause/costi congestione: scenario 3 D:che succede se il traffico offerto da B cresce a dismisura?

42. Cause/costi congestione: scenario 3 (cont.) Un altro “costo” della congestione: • Quando un pacchetto è scartato, tutta la banda usata per consegnarlo è stata sprecata

43. Controllo end-to-end Ritmo di trasmissione limitato da una finestra di congestione, Congwin, sul numero di segmenti: w * MSS throughput = Byte/sec RTT Controllo della congestione in TCP Congwin • w segmenti, ciascuno con MSS byte inviati in un RTT:

44. Due “fasi” Slow start (avvio lento) congestion avoidance (evitare la congestione) Variabili importanti: Congwin threshold: definisce la soglia di passaggio da una fase di slow start a quella di controllo di congestione successiva “Stima” della banda disponibile: Idealmente: trasmissione al massimo ritmo possibile (Congwin max. possibile) senza perdita AumentaCongwin fino alla perdita (congestione) Perdita: decrementaCongwin, poi inizia nuovamente la stima (aumento) Controllo della congestione in TCP (2)

45. Aumento esponenziale della dim. finestra (per RTT) Perdita: timeout (Tahoe TCP) e/o tre ACK duplicati (Reno TCP) Algoritmo Slowstart Tempo TCP: Slow start Host A Host B Un segmento RTT Iniz.: Congwin = 1 for (each segment ACKed) Congwin=Congwin++ until (loss event OR CongWin > threshold) Due segmenti Quattro segmenti

46. TCP: controllo della congestione Controllo congestione /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart 1 1: TCP Reno non fa slowstart dopo Ricezione di tre ACK duplicati

47. Due sessioni contemporanee: Aumento additivo dà pendenza 1, quando il throughput cresce Decremento moltiplicativo diminuisce il throughput in modo proporzionale perché TCP è equo? Suddivisione equa della banda R Perdita: decr. Finestra di un fattore 2 Controllo congestione: incremento additivo Throughput connessione 2 Perdita: decr. Finestra di un fattore 2 Controllo congestione: incremento additivo Throughput connessione 1 R