Esercizi – Strato di trasporto

Esercizio 5.4.
Si mostri lo pseudoheader e il segmento TCP con socket di sorgente <10.0.0.1, 8191>, socket di destinazione <192.168.255.17, 1539>, SN = 17.000, AN = 152, window = 1000, payload “Dante” e tutti gli altri campi posti a zero, che vengono utilizzati per il calcolo del checksum, determinandone anche il valore decimale ottenuto.

Segmento TCP e pseudoheader associato così ottenuti sono mostrati in Figura E5.1a, considerando che il numero di protocollo TCP è 6 e il numero di byte del segmento TCP è 25. L’operazione di giustificazione a 16 bit per il calcolo del checksum è mostrata in Figura E5.1b (poiché il segmento TCP contiene un numero dispari di byte, occorre aggiungere il byte 0 in coda al segmento), risultando in un checksum (decimale) uguale a 45.412.

Figura E5.1 Segmento TCP con pseudoheader (a) e calcolo checksum (b) secondo l’Esercizio 5.4.

Esercizio 5.7.
Si consideri una connessione TCP che adotta il valore MSS di default e MSL = 2 min. Si vuole determinare la massima capacità C di un flusso IP che supporta la connessione TCP, affinché non possano mai trovarsi in rete due byte con lo stesso numero ipotizzando che i datagrammi IP abbiano un header di 20 byte.

L’equazione fornisce la massima capacità della connessione TCP, e cioè

   

Poiché ogni segmento TCP ha un payload di MSS = 536 byte e un header di 20 byte, cui si aggiunge l’header di 20 byte del datagramma IP, ne consegue che la capacità massima C del flusso IP è

   

Esercizio 5.9.
Si consideri il trasferimento di dati tra due stazioni, A e B, attraverso una connessione TCP con le seguenti ipotesi: (i) solo la stazione A riceve dalla propria applicazione dati da inviare e in particolare un primo blocco di 4500 byte al tempo t = 0 e un secondo blocco di 4000 byte al tempo , dove il tempo di trasmissione di un segmento di dimensione massima MSS = 1500 byte è dato da e è il ritardo di propagazione tra le due stazioni; (ii) il secondo segmento inviato dalla stazione A non viene ricevuto dalla stazione B; (iii) il tempo di trasmissione di un riscontro è ; numerazione iniziale = 1000 e = 500. Si chiede di determinare per questo caso il valore del time-out To oltre il quale la procedura fast retransmit consente di ritrasmettere più velocemente il segmento perduto.

Determinare il valore richiesto per il time-out richiede di calcolare il tempo richiesto alla procedura fast retransmit per recuperare il segmento perduto. Come mostrato in Figura E5.2, la stazione A, dopo il riscontro del primo segmento, riceve 3 ACK ripetuti con stessa numerazione AN, cosa che indica perdita di segmento secondo la procedura fast retransmit. Alla ricezione del terzo riscontro ripetuto la stazione A procede a ritrasmettere il segmento che si assume sia andato perso. Il tempo che intercorre tra la fine della prima trasmissione del segmento e l’inizio della sua ritrasmissione determina il valore del parametro richiesto. Considerando l’istante di arrivo del secondo blocco di dati, si ricava come

   

Figura E5.2 Recupero di segmento perduto con procedura fast retransmit secondo l’Esercizio 5.9.

Esercizio 5.10.
Si chiede di disegnare il diagramma temporale dello scambio di segmenti TCP descritto nell’Esempio 5.7 mostrando anche lo stato del buffer di trasmissione nella direzione B-A, ipotizzando ora che l’entità TCP B riceva un blocco di dati di 2500 byte invece che di 1000 byte, che l’apertura della finestra di ricezione sia di 3000 byte in direzione A-B e di 2000 byte in direzione B-A.

A differenza dello schema di Figura 5.18, ora la stazione B invia tre segmenti invece di uno, dei quali due da 1000 byte e uno da 500 byte. Come mostrato in Figura E5.3, a causa dell’apertura di 2000 byte della finestra da B ad A, l’ultimo segmento può essere trasmesso da B solo dopo aver ricevuto il riscontro del primo segmento inviato. Inoltre la trasmissione da parte di B del secondo segmento richiede di ritardare il riscontro alla stazione A del secondo segmento inviato da parte di A. Ciò implica che l’invio del quinto segmento venga leggermente ritardato fino all’arrivo in A del riscontro in questione, rispetto a quanto accade nella Figura 5.18. La Figura E5.3 mostra anche lo stato del buffer di trasmissione nella stazione B.

Figura 5.18 Scambio di segmenti TCP secondo l’Esempio 5.7 (Esercizio 5.10).

Figura E5.3 Scambio di segmenti TCP con finestra A-B di 3000 byte e B-A di 2000 byte secondo l’Esercizio 5.10.

Esercizio 5.13.
Si calcoli il nuovo valore del round trip time se la stima corrente è RTT = 15 ms e si ricevono 5 riscontri che risultano nei ritardi misurati di RTT uguali a 18, 23, 24, 32 ms. Si assumano i valori suggeriti per i coefficienti peso. e .

L’aggiornamento del parametro RTT si basa sull’equazione dove rappresenta il valore corrente e indica l’ultima rilevazione ricevuta e il parametro assume il valore di 1/8. Quindi si ricavano facilmente i nuovi valori di RTT come mostrato di seguito

   

   

   

   

Si osserva dunque come il meccanismo di aumento con media mobile pesata determini una variazione più lenta della variazione effettivamente rilevata nel parametro RTT.

Esercizio 5.16.
Due host sono collegati tramite una rete che rende disponibile un collegamento su canale radio di lunghezza d = 80 km e di capacità costante C = 80 Mbit/s. Viene utilizzato il protocollo di trasporto TCP per effettuare il trasferimento di segmenti dall’host A all’host B, ognuno di dimensione fissa MSS = 1000 byte, con ampiezza iniziale della congestion window Cwnd = 1 MSS per i due valori della soglia = 32 MSS e = 4 MSS, con inizio trasmissione del primo segmento al tempo t = 0. Ipotizzando che non avvengano errori durante il trasferimento dei dati e che la lunghezza dei messaggi di riscontro sia trascurabile, si chiede di valutare il tempo T necessario per completare il trasferimento di un file da 27,5 kbyte da A a B per ciascuno dei due valori e .

Il round trip time, RTT, tra i due host è dato dal tempo necessario per ricevere il segmento di riscontro in risposta a un segmento di richiesta. Il tempo di trasmissione s di un segmento di richiesta e il tempo di propagazione sono dati da

   

   

Dato che i riscontri hanno lunghezza trascurabile, il parametro RTT è dato dalla somma del tempo di trasmissione del segmento di richiesta e del doppio del ritardo di propagazione tra i due host, e cioè

   

La valutazione del tempo di trasferimento del file richiede di individuare l’istante t dopo il quale la trasmissione della stazione A diventa continua, dato che la dimensione iniziale della congestion window determina un’utilizzazione parziale della capacità disponibile. Il trasferimento di 27,5 kbyte di dati richiede l’invio di 28 segmenti di dimensione fissa MSS. Nel caso del valore di soglia = 32 MSS, come mostrato in Figura E5.4, la quantità di segmenti trasmessi raddoppia nelle prime tre “finestre” di durata RTT, nelle quali vengono trasmessi 1 +2 + 4 = 7 segmenti. La trasmissione del successivo blocco di 8 segmenti richiede un tempo di 800 che è maggiore di RTT. La trasmissione diventa dunque continua all’istante

   

Con l’avvio della trasmissione continua non riveste più importanza l’ampiezza Cwnd della congestion window che non raggiunge comunque il valore sella soglia e quindi la regione in cui si opera è sempre slow start. Il tempo totale T richiesto per il trasferimento del file è dato da

   

Figura E5.4 Scambio di segmenti TCP con secondo l’Esercizio 5.16.

Nel caso del valore di soglia il raddoppio della congestion window è limitato al valore . Quindi, come rappresentato in Figura E5.5, dopo 3 “finestre” di durata RTT la congestion window aumenta di un MSS per ogni ulteriore finestra, poichè si opera in regione congestion avoidance. Dato che in un tempo RTT possono essere trasmessi 6,33 segmenti, occorrono 5 “finestre” di durata RTT prima che inizi una trasmissione continua da parte della stazione A, che ha luogo al tempo

   

Quindi, dato che vengono trasferiti 1 + 2 + 4 + 5 + 6 = 18 segmenti prima che inizi la trasmissione continua, il tempo totale richiesto per il trasferire del file mediante 28 segmenti di dimensione MSS è ora dato da

   

Figura E5.5 Scambio di segmenti TCP con secondo l’Esercizio 5.16.

Esercizio 5.21.
Si chiede di rappresentare l’andamento dell’apertura della congestion window per i protocolli TCP Tahoe e TCP Reno per i primi 40 intervalli di RTT nell’ipotesi che: (i) uno dei segmenti inviati al tempo 13 RTT venga perso e vengano ricevuti solo ACK duplicati; (ii) che nell’intervallo (14-15) RTT la rete sia guasta e nessun segmento venga trasmesso; (iii) la rete vada fuori servizio nell’intervallo (23-25) RTT. I valori iniziali sono: soglia tra le due regioni Ssthresh = 16 MSS, congestion window Cwnd = 1 MSS, time-out = 2 RTT. La trasmissione ha inizio al tempo 1 RTT.

L’andamento del parametro Cwnd per i due protocolli è riportato in Figura E5.6. Per i primi 5 cicli di RTT si opera nella regione slow start con aumento esponenziale di Cwnd, per poi entrare nella regione di congestion avoidance caratterizzata da aumento lineare. La perdita di segmento trasmesso al tempo 13 RTT viene rilevata al tempo 14 RTT per mezzo di 3 ACK duplicati con il protocollo TCP Reno, al tempo 15 RTT per mezzo della scadenza del time-out con il protocollo TCP Tahoe. Il nuovo valore della soglia diviene Ssthresh = 12 MSS, dato che il numero di segmenti trasmessi privi di riscontro è Flightsize = 24. Nel caso del protocollo TCP Tahoe, la congestion window riparte dal valore unitario e aumenta in modo esponenziale fino al nuovo valore di soglia per poi aumentare in modo lineare. Nel caso del protocollo TCP Reno la congestion window riparte dal valore Cwnd = Ssthresh = 12 MSS e l’aumento continua in modo lineare dato che ci si trova nella regione congestion avoidance. Al verificarsi di perdita rivelata della scadenza del time-out al tempo 25 RTT la soglia assume il nuovo valore Ssthresh = 8 MSS con il protocollo TCP Tahoe e Ssthresh = 10 MSS con il protocollo TCP Reno, cioè metà dell’ultimo valore di Cwnd, che indica anche il numero di segmenti inviati privi di riscontro. In entrambi i casi la nuova apertura della congestion window è quella minima Cwnd = 1 MSS. All’aumentare di RTT l’apertura aumenta in modo esponenziale in entrambi i protocolli fino al raggiungimento delle rispettive soglie, dopo cui l’aumento torna a essere lineare.

Figura E5.6 Apertura della congestion window secondo l’Esercizio 5.21.