Reti di calcolatori - Livello trasporto

Ritrasmissione basata sul tempo

Il meccanismo è quello del conto alla rovescia. Lato receiver, la perdita del pacchetto non si nota, semplicemente il receiver non vedrà arrivare dei dati per un po' di tempo però le azioni e gli stati lato receiver non cambiano perché il pacchetto è andato perso, quindi il receiver non riceve nulla. Questo problema della gestione delle perdite è un problema del sender.

Il ruolo del sender

Il sender deve:

• Far partire un cronometro dopo la trasmissione di un pacchetto, anche se è una ritrasmissione
• Se l’evento è la ricezione di un ACK, allora deve interrompere il timer al ricevimento di un ACK
• Se l’evento è un NAK, allora deve rispondere alle interruzioni del timer

La macchina a stati finiti

La novità è il timeout, quindi l’evento di timeout e l’azione di far partire un timer. Gli stati sono ancora 4 perché siamo ancora fermi su uno stop-and-wait con sequenze 0 e 1. Lo stato iniziale è: pronto a trasmettere dati con sequenza 0. Arrivano dati, creo un pacchetto che ha sequenza 0, che contiene i dati e il checksum: udt_send(sndpkt), start_timer. Si passa poi in uno stato di attesa per l’ACK di quel pacchetto e si rimane in attesa di ricevere un ACK per il pacchetto appena trasmesso. Quando ricevo qualcosa che contiene degli errori oppure è un ACK duplicato quindi è una riconferma del pacchetto precedente, oppure l’evento di timeout, quindi se scade il timeout si ha la ritrasmissione quindi udt_send(sndpkt) e faccio ripartire il timer.

Dallo stato di attesa di una conferma per il pacchetto 0 si passa a poter trasmettere dei nuovi dati quando si riceve un qualcosa che non contiene errori e che è un ACK atteso, quindi quello relativo all’ultimo pacchetto inviato. Per gli altri stati, la macchina a stati finiti è simmetrica. Dallo stato di attesa di nuovi dati per creare un segmento con sequenza 1, si passa in attesa dell’ACK quando si ricevono dei dati come per lo stato di attesa dello 0.

Notiamo in basso a sinistra rdt_rcv(rcvpkt) che provoca l’azione nulla. Quindi, nel momento in cui sono in attesa di ricevere nuovi dati per creare un nuovo pacchetto, può capitare di ricevere dei pacchetti, essi possono essere delle conferme ricevute, ma non provocano nessuna azione, quindi un’azione nulla. Perciò si rimane in quello stato di attesa, quindi nello stesso modo se aspettiamo l’attesa per il pacchetto 1, se scade il timeout, si ha la ritrasmissione, si fa ripartire il timer e la ricezione di qualcosa che contiene errori oppure è un ACK di 0, allora azione nulla e si rimane nello stato di attesa.

Rispetto alla versione 2.2 vista prima, c’è in più la gestione del timer e l’interruzione. Quindi, se si riceve la conferma, si ferma il timer e si trasmettono altri dati invece di aspettare la scadenza. Il dato è quindi stato ricevuto correttamente.

Lato receiver

La macchina a stati finiti è esattamente come quella di prima. Infatti, la perdita di un pacchetto da receiver non viene nemmeno vista. Si noterà soltanto un ritardo o delay tra un pacchetto e l’altro, ma come eventi non cambia nulla. La macchina a stati finiti nel caso del receiver è uguale a quella della versione precedente che gestiva gli errori.

Riordino di pacchetti

Consideriamo il caso di timeout prematuri, ad esempio perché il pacchetto ha subito dei forti ritardi. Avremo poi una ritrasmissione di un pacchetto che arriva con forte ritardo, succede quindi che dopo un po' si ha la ricezione di una conferma del pacchetto 0 (ma si fa riferimento al primo invio, non al secondo). Questo ACK provoca, lato sender, la trasmissione del pacchetto P1. Ho poi la ricezione di P0 duplicato, questo P0 lato receiver viene preso per buono per la versione di protocollo fatta finora, è la sequenza attesa, è un pacchetto corretto, però è lo stesso pacchetto di prima. È infatti un duplicato quindi dovrebbe essere scartato, dunque questo protocollo in questa versione non va ancora bene.

Prestazioni stop-and-wait

Il problema di fondo di questi protocolli visti è lo stop-and-wait, infatti stiamo parlando di un protocollo che trasmette un pacchetto e poi la trasmissione si ferma in attesa di ricevere un ACK. Proviamo a fare dei conti sull’utilizzo misurato lato applicativo di questo canale, quindi noi stiamo trasmettendo dei dati a una certa frequenza che è limitata dalla ricezione dell’ACK. Infatti, abbiamo detto che sono le conferme che sbloccano la trasmissione; proviamo a pensare a un canale di 1Gbit quindi un link di quelli intercontinentali, ad alta velocità, e un ritardo di propagazione abbastanza elevato, ad esempio 1msec.

Quindi, potenzialmente abbiamo una banda di 1Gbit ma abbiamo un protocollo del tipo stop-and-wait: possiamo dire che lato applicativo non stiamo usando il 100% della nostra banda. Per calcolare l’utilizzo di questo canale, possiamo dire che la parte azzurra è la parte di trasmissione buona, quindi con la trasmissione del pacchetto noi stiamo effettivamente utilizzando il canale, quello che si chiama RTT (round trip time) è il tempo di attesa della conferma. Questo è tempo perso in cui il sender non può trasmettere e lato sender il canale non è utilizzato, questa banda disponibile non è utilizzata.

Quindi, se diciamo che trasmettiamo un pacchetto di 1000 byte, il suo tempo di trasmissione, cioè la parte azzurra, è L/R, cioè 8 microsec. Potremo trasmettere dati nuovi quando ci arriva la conferma e questo ACK arriva dopo un tempo pari a RTT, cioè il tempo di andata e ritorno, propagazione, trasmissione dell’ACK (che in questo caso possiamo anche considerarlo trascurabile) e propagazione all’indietro del segnale. Quello che pesa sono i 2 millisecondi di attesa di andata e ritorno, quindi in questo caso l’RTT sarà 2008 millisecondi cioè 2 tempi di propagazione a cui sommo L/R. Questi 2008 millisecondi è il tempo in cui il canale è bloccato sulla trasmissione di un pacchetto da 1000 byte, quindi l’utilizzo lo calcoliamo come tempo buono diviso tempo totale cioè 8/(2008).

Possiamo parlare anche di throughput, infatti i dati non vengono trasmessi alla frequenza di 1Gbit ma stiamo trasmettendo 1000 byte in poco più di 2 millisecondi, quindi un throughput molto inferiore rispetto alla banda offerta proprio a causa di questo stop-and-wait.

Protocolli a finestra scorrevole, pipelined o sliding-window

L’evoluzione è parlare di protocolli come il Go-Back-N (GBN) e il Selective Repeat (SR) che sono detti protocolli a finestra scorrevole. L’idea è usare un po' di più la banda, quindi invece di trasmettere un pacchetto ne trasmetto un po' di più, comunque però rimane l’idea fondamentale che la trasmissione è regolata dalla ricezione di ACK, quindi comunque rimane l’idea di limitare la frequenza trasmissiva però non si trasmette più un pacchetto ma una finestra di trasmissione, quindi un certo numero di segmenti e pacchetti prima di doversi fermare in attesa di ricevere ACK.

Il protocollo si complica perché uno spazio di numeri di sequenze di un bit non è più sufficiente, non abbiamo più solo un pacchetto e poi il successivo ma ci saranno n pacchetti in giro quindi n sequenze da gestire e inoltre anche perché sono pacchetti che potrebbero dover essere ritrasmessi e così via. Inoltre, un’altra complicazione è nel buffer, sarà infatti necessario adottare sender e a volte anche il receiver di aree di memoria per memorizzare questi pacchetti che non sono ancora stati riscontrati, quindi pacchetti che sono lì, trasmessi in attesa di conferma che potrebbero richiedere una ritrasmissione.

TCP sarà un mix dei due protocolli Go-Back-N e Selective Repeat. Il concetto importante da capire è che comunque siamo su un protocollo limitato che limita la frequenza in base alla ricezione degli ACK. L’istante di ricezione dell’ACK è quello di prima, quindi io trasmetto un pacchetto e ricevo conferma dopo un tempo pari a RTT+trasmissione del pacchetto L/R. È un protocollo migliore dal punto di vista delle performance perché nello stesso intervallo di tempo, negli stessi 2008 microsecondi di prima, non trasmetto un solo pacchetto ma ad esempio nel caso seguente ne trasmetto 3, quindi triplica l’utilizzo e il throughput nello stesso intervallo di tempo.

Quando ricevo conferma sul primo pacchetto questo sblocca la trasmissione, se ho al massimo 3 pacchetti il protocollo mi dice che posso avere al massimo 3 pacchetti in giro trasmessi e non riscontrati, quindi trasmetto 1, 2, 3 e mi stoppo. Arriva una conferma sul primo pacchetto che mi conferma il pacchetto e inoltre mi dice che ho solo 2 pacchetti fuori, trasmessi, e non riscontrati, quindi sblocca la trasmissione e mi consente di trasmettere il 4° pacchetto e, se tutto va avanti regolare, allora riceverò anche la conferma sul 2° e 3° pacchetto e ognuno di questi ACK libera un posto, quando confermo un pacchetto do’ spazio per la trasmissione di un altro pacchetto.

Sono detti protocolli a finestra scorrevole perché questi pacchetti avranno delle sequenze e la ricezione dell’ACK fa sì che man mano vengano usate le sequenze successive per l’invio di nuovi pacchetti. Questi protocolli sono detti sliding window perché quella che si chiamerà la finestra di trasmissione, è la quantità massima di dati che un sender può avere in giro trasmessi e non riscontrati, quindi in generale la base comune di tutti questi protocolli è il fatto di avere una quantità massima di pacchetti non riscontrati, questo vale sia per il Go-Back-N che per il Selective Repeat.

C'è una differenza fondamentale tra i due protocolli: nel Go-Back-N il receiver conferma solamente dati che riceve corretti e in ordine, quindi se si riceve un pacchetto fuori sequenza, questo non viene confermato, mentre nel selective repeat si ha una conferma selettiva, quindi se un receiver, cioè se un nodo, riceve dei dati corretti ma non in ordine, questi vengono confermati positivamente, se lo può permettere perché nel selective repeat il receiver ha la possibilità di bufferizzare i pacchetti fuori ordine, cosa che nel Go-Back-N non c'è.

Altra differenza: nel Go-Back-N c'è un timer unico, quindi il timer viene fatto partire sul pacchetto più vecchio, cioè che ha la sequenza più piccola, cioè sul pacchetto che è stato trasmesso per primo e che non è ancora stato confermato.