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 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

Vediamo 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.

Stato iniziale: pronto a trasmettere dati con sequenza 0, arrivano dati, creo

un pacchetto che ha sequenza 0 che contiene i dati e che contiene 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 trasmetto quando ricevo un qualche cosa 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 qualche cosa che non contiene

errori e che è un ACK e che è l’ACK atteso quindi quello relativo all’ultimo

pacchetto inviato.

Per gli altri stati la macchina a stati finiti è simmetrica, quindi 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, queste 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,

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 delaversione 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 1000byte, il suo tempo di trasmissione, cioè la

parte azzurra, è L/R, cioè 8microsec, 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à 2008millisecondi 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 1000byte, 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 1000byte 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. E’ 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 paccchetto 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 si 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 &eg