ESERCIZIARIO. Risposte ai quesiti:

Documenti analoghi
Livello di trasporto: meccanismi trasferimento dati affidabile

Livello di trasporto: meccanismi trasferimento dati affidabile, TCP

la trasmissione è regolata solamente dall algoritmo per il controllo del flusso prima di inviare l ACK.

Soluzione dell esercizio 2 (TCP) dell esame del 16 giugno 2015

Esercitazione. Livello di Trasporto [Capitolo 3]

Controllo di congestione

Reti di Comunicazione e Internet

Livello trasporto. Servizi del livello trasporto

Controllo di Congestione in Reti Internet Docente: Vincenzo Eramo

CORSO DI RETI SSIS. Lezione n.3 9 novembre 2005 Laura Ricci


Politecnico di Milano Advanced Network Technologies Laboratory. Esercizi sul TCP

Controllo della congestione

Corso di Laurea in Ingegneria Informatica. Corso di Reti di Calcolatori I

Principi di trasferimento affidabile

R. Cusani, F. Cuomo: Telecomunicazioni - DataLinkLayer: Gestione degli errori, Aprile 2010

Telematica di Base. IL Livello di Trasporto TCP

Gestione della Connessione in TCP

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30

Esercizi: Telecomunicazioni parte Reti

Fondamenti di Internet e Reti

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 24 Gennaio 2005, ore 15.00

Introduzione (parte III)

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Lunedì 7 Febbraio 2005, ore 15.00

Transmission Control Protocol (TCP) Andrea Detti

Livello trasporto in Internet

Strato di trasporto. Livello di applicazione SAP. Livello di trasporto. Livello di rete SAP

I protocolli UDP e TCP

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 20 Luglio 2005

Fondamenti di Internet e Reti Esercizi sui meccanismi di controllo di errore e sul livello di trasporto

Livello Trasporto. Liv. Applic. Liv. Transport. Transport Entity. Liv. Network. Trasporto

Capitolo 3 Livello di trasporto

Reti di calcolatori TCP/IP. Slide a cura di Simon Pietro Romano

J+... J+3 J+2 J+1 K+1 K+2 K+3 K+...

TCP. Servizio di Trasporto Affidabile. Transmission Control Protocol. Caratteristiche di TCP 1

IL LIVELLO TRASPORTO Protocolli TCP e UDP

RTT costante pari a 0.5 secondi; primo RTO= 2*RTT;

Prova in itinere 5 Maggio 2016

Internet (- working). Le basi.

Configurazione delle interfacce di rete

Livello di trasporto e TSAP

IL LIVELLO TRASPORTO Protocolli TCP e UDP

Strato trasporto. Per capir meglio la cosa analizziamo il seguente esempio:

Prova in itinere - Rete Internet (ing. Giovanni Neglia) Mercoledì 23 Maggio 2007, ore 15.00

Prova completa - Rete Internet (ing. Giovanni Neglia) Lunedì 25 Giugno 2007

II prova in itinere - Rete Internet (ing. Giovanni Neglia)

Prof. Ing. Maurizio Casoni Dipartimento di Ingegneria dell Informazione Università degli Studi di Modena e Reggio Emilia

Funzioni del protocollo TCP

Le Reti Informatiche

Transcript:

ESERCIZIARIO Risposte ai quesiti: 3.1. Sebbene qualsiasi numero di porta possa essere utilizzato per il client e il server in questa comunicazione privata (il numero può anche essere lo stesso), si raccomanda di seguire gli intervalli specificati dall ICANN: a. Il numero di porta del client dovrebbe essere scelto nell intervallo 49152 65535. b. Anche il numero di porta del server dovrebbe essere scelto nell intervallo 49152 65535. c. S i consiglia di scegliere i numeri di porta diversi per il server e il client per facilitare il debug dei programmi. 3.2. Controlliamo ogni protocollo uno per uno: a. Può essere il protocollo Stop and Wait che ha la dimensione della finestra di ricezione e di trasmissione uguale a 1. b. Può essere il protocollo Go Back N che ha la dimensione della finestra di ricezione uguale a 1 e la dimensione della finestra di invio dei pacchetti uguale a n. c. Il protocollo utilizzato non può essere il Selective Repeat perché la dimensione di entrambe le finestre dovrebbe essere la stessa (1), e in tal caso si avrebbe che il protocollo usato è Stop and Wait e non Selective Repeat. 3.3. Innanzitutto descriviamo i vantaggi e gli svantaggi di ciascun meccanismo: a. Il vantaggio di utilizzare il protocollo Go Back N è che si può avere una maggiore finestra di invio. Siamo in grado di inviare più pacchetti prima di attendere il loro riscontro. Lo svantaggio di questo protocollo è che la dimensione della finestra di ricezione è solo 1. Il ricevitore non può accettare e memorizzare i pacchetti ricevuti fuori sequenza, che vengono perciò scartati. Scartare tali pacchetti significa che il mittente deve rispedirli, con conseguente congestione della rete e riduzione della capacità della condotta (quantità di pacchetti che possono essere inviati senza riscontro). In questo modo il vantaggio di aver una finestra di invio maggiore può essere vanificato riempiendo la rete con pacchetti rispediti. b. Il vantaggio di utilizzare il protocollo Selective Repeat è che la finestra di ricezione può essere molto più grande di 1. Questo consente di memorizzare i pacchetti ricevuti fuori sequenza ed evita che questi vengano inviati nuovamente, congestionando la rete. D'altra parte, la dimensione della finestra di trasmissione di questo protocollo è la metà del Go Back N, il che significa che possiamo inviare meno pacchetti prima di attendere il riscontro. c. Se il prodotto banda ritardo della rete è grande, l'affidabilità è buona e il ritardo è basso, si dovrebbe scegliere il protocollo Go Back N per utilizzare più della capacità della rete. D'altra parte, se il prodotto banda ritardo è piccolo, la rete non è molto affidabile, o la rete introduce lunghi ritardi, abbiamo bisogno di usare il Selective Repeat.

3.4. I pacchetti a livello di trasporto vengono incapsulati in datagrammi al livello rete. Il router attraverso cui i datagrammi devono passare per raggiungere la loro destinazione può essere congestionato e scartare pacchetti. 3.5. Il resto dei pacchetti (2 m 2) dovrebbero essere in transito, riempiendo la condotta. La dimensione della finestra di ricezione è impostata ad 1 per accettare un solo pacchetto, quello in attesa, e non i pacchetti fuori sequenza. Il ricevente non può essere sovraccaricato perché mantiene un solo pacchetto nella sua finestra di ricezione. Quando il pacchetto nella finestra di ricezione viene consumato dal protocollo del livello sovrastante, allora la finestra scorre per consentire di ricevere il successivo pacchetto in transito. Se qualsiasi pacchetto in transito arriva prima dello scorrimento della finestra esso viene scartato. 3.6. Il campo protocollo del datagramma (vedi figure 4.15 e 4.16 nel Capitolo 4) definisce il protocollo di livello trasporto che dovrebbe ricevere il pacchetto del livello di trasporto. Se il valore è 06, il protocollo è TCP, se il valore è 17, il protocollo è UDP. 3.7. UDP è preferibile perché per ogni blocco di dati può essere usato un datagramma utente. 3.8. La risposta è positiva. Non c'è nulla nel protocollo UDP o TCP che richiede l'uso del protocollo IP. Un datagramma utente UDP o un segmento TCP può essere incapsulato in un frame Ethernet. Tuttavia, il campo protocollo del frame Ethernet deve specificare quale protocollo viene direttamente utilizzato. 3.9. Ci sono due parti (estremità) coinvolte in una comunicazione bidirezionale. TCP consente a ciascuna parte di interrompere l'invio, mentre l'altra parte sta ancora inviando dati. Ciò significa che c è bisogno di almeno due segmenti FIN (o segmenti dati in cui è impostato il bit FIN). Dal momento che ogni segmento FIN dovrebbe essere riscontrato, di solito sono necessari quattro segmenti per la chiusura della connessione. A volte il secondo segmento FIN può essere combinato con il segmento ACK per ridurre il numero di segmenti a tre. 3.10. Il modo in cui viene determinato il numero di sequenza cambia in base al fatto che il segmento sia il primo oppure no. a. Il numero di sequenza del primo segmento è il valore ISN, che è normalmente selezionato in base alla RFC 793. b. Il numero di sequenza di qualsiasi segmento escluso il primo è dato dal numero di sequenza del segmento precedente più la quantità di numeri di sequenza consumati dal segmento precedente. In altre parole, il numero di sequenza di un segmento è y = x + n, in cui x è il numero di sequenza del segmento precedente ed n è la quantità di numeri di

sequenza consumati dal segmento precedente. Se il segmento precedente non consuma numeri di sequenza, n = 0. 3.11. a. Un segmento SYN consuma un numero di sequenza. b. Un segmento ACK non consuma alcun numero di sequenza. c. Un segmento SYN + ACK consuma un numero di sequenza, perché si tratta di un segmento SYN. d. Un segmento dati consuma n numeri di sequenza, dove n è il numero di byte trasportati dal segmento. 3.12. Non si può dire. La dimensione del campo finestra permette una finestra di 2 16 byte, ma il numero di sequenza è 2 32. La dimensione della finestra è sicuramente molto più piccola (in realtà 2 16 volte più piccola) della metà dell intervallo dei numeri di sequenza. Il requisito di ogni protocollo, Go Back N e Selective Repeat, è soddisfatto. Tuttavia, come abbiamo accennato nel testo, TCP è più vicino a Selective Repeat in altri aspetti. 3.13. a. La dimensione massima dell'intestazione TCP è di 60 byte (20 byte di intestazione e un massimo 40 byte di opzioni). b. La dimensione minima dell intestazione TCP è di 20 byte. 3.14. Un segmento FIN chiude la connessione in una sola direzione. La parte che ha inviato il segmento FIN non può inviare dati all'altra parte, ma ha bisogno di riscontrare i dati ricevuti dalla controparte. L'altra parte può invece ancora inviare dati e riscontri. Per chiudere completamente la connessione, sono necessari due segmenti FIN, uno in ogni direzione. Naturalmente, i segmenti FIN e ACK possono sempre essere combinati. 3.15. Per esempio, il SYN e RST flag non possono essere impostati congiuntamente in un segmento. Infatti uno dei due richiede l'inizio di una connessione mentre l altro richiede che la connessione sia interrotta. Un altro esempio è la combinazione di SYN e FIN. 3.16. Questo viene fatto attraverso i riscontri e le ritrasmissioni. Se un pacchetto viene perso o danneggiato, sarà rispedito. Come analogia, si assuma che il servizio postale sia inaffidabile. Quando si invia una lettera ad un amico, si può chiedere conferma con una cartolina. Se non si riceve la cartolina, è possibile inviare di nuovo la copia della lettera finché non si riceve la conferma. 3.17. Una connessione è caratterizzata da una coppia di socket address, uno per ciascuna estremità. Sebbene i socket address dal lato di Gabriele siano gli stessi in questo caso, i

socket address dal lato di Gaia sono diversi. Ogni socket address dal lato di Gaia ha un diverso numero di porta effimero. 3.18. La finestra di invio nel TCP inizialmente ha la stessa dimensione della finestra di ricezione, ma con il crearsi della congestione in rete, può diventare più piccola della finestra di ricezione. Non può mai diventare più grande della finestra di ricezione. La finestra di invio diventa più piccola della dimensione originale a causa della congestione o perché determinata dal ricevente. 3.19. La risposta dipende dal fatto che il segmento trasporti dati o meno. a. Se il segmento trasporta dati, il numero di sequenza definisce il numero dei primi byte del segmento. b. Se il segmento non trasporta dati (puro segmento di controllo), il numero di sequenza identifica il segmento stesso. 3.20. L'uso del checksum in UDP è facoltativo. Se il mittente non utilizza il checksum riempie allora tale campo con sedici zeri. L'uso del checksum in TCP, invece, è obbligatorio. Il mittente deve calcolare il checksum altrimenti, il calcolo del checksum al destinatario fallisce e il segmento viene scartato. 3.21. Il segmento ricevuto è un duplicato. Il client TCP deve scartare il segmento e inviare immediatamente un ACK con numero di riscontro 2001. Questa reazione permette al server di aggiornarsi se l'ack precedente con numero di riscontro 2001 è in qualche modo andato perso (Regola 6 della generazione degli ACK). 3.22. Il server ha bisogno di memorizzare i nuovi byte e invia immediatamente un ACK con numero 2901. Questa reazione impedisce la ritrasmissione del segmento precedente da parte del client (Regola 3 nella generazione degli ACK). 3.23 Il server ha bisogno di memorizzare i nuovi byte, ma invia un segmento con numero di sequenza 4001 e numero di riscontro 8001 (piggybacking). Ciò consente di risparmiare banda perché i dati devono andare nella direzione opposta, ed è meglio riscontrare i byte ricevuti nello stesso pacchetto (regola 1 in generazione ACK). 3.24. Le sei regole di cui abbiamo parlato per la generazione degli ACK sono relative al controllo di flusso e degli errori e sono applicabili durante la fase di trasmissione di dati, non durante la fase di chiusura della connessione. In questo caso, un SYN deve essere riscontrato da un segmento (SYN + ACK) se il server accetta la connessione o un segmento RST altrimenti.

3.25. Le sei regole di cui abbiamo parlato per la generazione degli ACK sono relative al controllo di flusso e degli errori e sono applicabili durante la fase di trasmissione di dati, non durante la fase di chiusura della connessione. In questo caso, il segmento FIN dovrebbe essere riscontrato immediatamente se non vi sono dati da inviare o riscontrato nel successivo segmento dati. Risposte ai problemi: 3.1 Il numero di sequenza di qualsiasi pacchetto può essere trovato usando la seguente relazione: seqno = (seqno iniziale + numero di pacchetto 1) mod 2 m dove m è il numero di bit usati per definire il numero di sequenza. Il numero di sequenza in questo caso è seqno = (0 + 100 1) mod 2 5 = 99 mod 32 = 3 3.2 Stop and Wait: Max Send Wsi ze = 1 Max Receive Wsiz e = 1 Go Back N: Max Send W size = 2 5 1 = 31 Max Receive Wsiz e = 1 Selective Repeat: Max Send W 5 size = 2 / 2 = 16 Max Send W 5 size = 2 / 2 = 16 3.3 L immagine seguente mostra gli stati e gli eventi. Il mittente ha bisogno di due stati: ready e blocking. Anche il destinatario ha bisogno di due stati. Per inviare un pacchetto, il mittente deve essere nello stato ready e ricevere dati dal livello applicazione. Il mittente non può inviare un pacchetto quando è nello stato blocking. Il destinatario accetta un pacchetto dal mittente quando è nello stato ready. Non può accettare un pacchetto quando è nello stato blocking. Quando il destinatario diventa pronto, invia un ACK e transita nello stato ready. Arrivata una richiesta dall applicazione Crea un pacchetto e invialo Arrivato un pacchetto Informa il livello applicazione Inizio Arrivato un ACK Pronto per ricevere un altro pacchetto Nessuna azione Mittente Invia un ACK Destinatario

3.4 L immagine seguente mostra il caso richiesto. Avviene quando un ACK è posticipato e il timeout scade. Il mittente re invia il pacchetto che è già stato riscontrato dal destinatario, il quale scarta il pacchetto duplicato, ma invia nuovamente il precedente ACK per informare il mittente che c è un ritardo nella rete. Mittente Livello di trasporto Livello di trasporto Destinatario Pacchetto 0 Pacchetto 0 Scarta (è un duplicato) Ricevuto ACK duplicato (il timeout potrebbe essere scaduto troppo presto) La ricezione di un ACK duplicato può allertare il mittente a incrementare il timeout per prevenire ritrasmissioni premature di pacchetti. Si noti che il destinatario ignora i pacchetti duplicati e non spedisce il secondo ACK, il mittente crede che il primo pacchetto sia perso e il primo ACK sta in realtà confermando il pacchetto che è stato rispedito. Gli ACK duplicati danno un idea di cosa sta accadendo. 3.5 Di seguito viene illustrato lo schema. Notare che il protocollo non fornisce controllo degli errori, pertanto se un pacchetto viene perso, il processo ricevente deve trovare una soluzione. Il livello trasporto non è consapevole di cosa è accaduto. I pacchetti possono anche essere consegnati in maniera non ordinata al processo ricevente. E nuovamente il processo ricevente che deve riordinare i pacchetti.

Mittente Livello di trasporto Ricevente Livello di trasporto Pacchetto 0 Pacchetto 1 Pacchetto 2 Pacchetto 3 Pacchetto 4 Perso 3.6 In ogni caso prima definiamo il prodotto bada ritardo (BDP) in bit e poi troviamo il numero di pacchetti: a. BDP = 1 Mbps * 20 ms = 20000 bit = 20 pacchetti b. BDP = 10Mbps * 20 ms = 200.000 bit = 100 pacchetti c. BDP = 1 Gbps * 4 ms = 4.000.000 bit = 400 pacchetti 3.7 Calcoliamo il round trip time (RTT) medio e il numero di pacchetti nella condotta (pipeline) prima di trovare le dimensioni delle finestre, il valore m, e il timeout. a. RTT medio = 2 * (5,000 Km)/(2 * 10 8 ) = 50 ms. b. Prodotto banda ritardo = 1Gbps * 50 ms = 50.000.000 bit. c. Prodotto banda ritardo = 50.000.000 bit / 50.000 bit = 100 pacchetti. d. La massima dimensione della finestra di invio dovrebbe essere 1000 pe r non avere più di 1000 pacchetti inviati senza riscontro (nella condotta). e. La massima dimensione della finestra di ricezione dovrebbe essere di 1000 pacchetti f. Sappiamo che (finestra d invio) (2 m 1) ovvero 1000 (2 m 1). Questo significa che dobbiamo scegliere (m 1) almeno uguale a 10, o m=11. I numeri di sequenza vanno quindi da 0 a 2047.

g. Il valore del timeout dovrebbe essere almeno pari al valore medio del RTT = 50 ms per evitare ritrasmissioni premature dei pacchetti e prevenire la congestione. 3.8 Di seguito viene mostrata la situazione. Mittente Destinatario a. Se il destinatario si aspetta un pacchetto con numero di sequenza 64 e i pacchetti con numeri di sequenza 62 e 65 sono già stati spediti ma non ancora riscontrati, significa che i due pacchetti con numeri di sequenza 64 e 65 sono in transito dal mittente al destinatario. b. Se il mittente aspetta un riscontro per il pacchetto 62, ma il valore R n = 64, significa che i pacchetti ACK con numeri di riscontro 62 e 63 sono in transito dal destinatario al mittente. 3.9 a. La dimensione minima è 8 byte (intestazione senza payload). b. Sebbene La dimensione massima in teoria sia 65535 byte, poiché un datagramma utente deve essere incapsulato in un singolo datagramma IP (UDP è senza connessione) e il massimo payload di un datagramma IP è 65515 byte (vedere Figura 4.15 nel Cap. 4), dovremmo dire che la dimensione massima di un datagramma UDP è 65515 byte. c. La dimensione minima del payload di livello applicazione è zero. d. La dimensione massima del payload di livello applicazione è 65.507 byte (65515 8). 3.10 a. Il numero di porta sorgente è dato dai primi 16 bit, ovvero (0045) 16 = 69. b. Il numero di porta destinazione è dato dai secondi 16 bit, (DF00) 16 =57088. c. La lunghezza totale del datagramma è data dai terzi 16 bit (0058) 16 =88 byte. d. La lunghezza dei dati è 88 8 = 80 byte. e. Il messaggio va da un server con un numero di parte basso (well known) a un client con un numero di porta alto (effimero). f. Il numero di porta noto 69 appartiene a TFTP. g. Il mittente non ha calcolato il checksum per questo pacchetto perché il valore checksum contiene tutti zeri. 3.11 Il numero (0111) 2 in decimale è 7. La lunghezza totale dell intestazione è quindi (7 x 4) = 28. L intestazione base è di 20 byte. Il segmento ha 28 20 = 8 byte di opzioni.

3.12 Le seguenti sono otto delle 64 possibili combinazioni che sono normalmente utilizzate: 000000 Un segmento dati senza riscontro 110000 Un segmento dati con dati urgenti e riscontro 010000 Un segmento ACK con o senza dati 000010 Un segmento SYN 011000 Un segmento dati con dati push e riscontro 000001 Un segmento FIN 010010 Un segmento ACK + SYN 000100 Un segmento RST 3.13 a. Il numero di sequenza nel segmento SYN è 2171. Il segmento SYN consuma un numero di sequenza; il prossimo numero di sequenza usato è 2172. b. Il numero di sequenza nel segmento dati è 2172 (che rappresenta il numero di sequenza del primo byte). I byte nei pacchetti sono numerati da 2172 a 3171. Notare che il client invia i dati con il secondo pacchetto (non c è ACK separato). c. Il numero di sequenza nel segmento FIN è 3172. Notare che il FIN consuma un numero di sequenza. 3.14 La sezione dati è di soli 16 byte. L intestazione TCP e di 20 byte. L efficienza è (16) / (16 + 20) = 0.444 44.4% 3.15 Di seguito si mostrano i tre segmento scambiati durante l instaurazione della connessione

Segmento SYN Segmento SYN + ACK Segmento ACK 3.16 Di seguito si mostra la chiusura della connessione. Assumiamo che questa avvenga mediante 3 way handshake perché il server non ha dati da spedire.

Segmento FIN + ACK Segmento FIN + ACK Segmento ACK 3.17 Di seguito si mostra il diagramma Apertura passiva / Apertura attiva / SYN Stati del client Stati del server

Notare che lo stato FIN WAIT2 non è usato in questo caso. Notare anche che ci sono cambiamenti nel lato server che non sono mostrati in Figura 3.50 (nel testo) perché dovuti a una questione implementativa. In questo caso, il server invia un FIN + ACK prima di transitare nello stato LAST ACK. 3.18 La probabilità di errore è molto bassa in quanto il numero di sequenza iniziale (ISN) ha un alta probabilità di essere unico. Assumiamo che Gaia e Gabriele Abbiano usato rispettivamente come ISN x ed y nella connessione precedente e z e t in questa connessione. Il vecchio segmento di ACK (terzo segmento) ha come numero di riscontro (y+1); il nuovo segmento di ACK dovrebbe avere (t + 1). Il server di Gabriele riconosce immediatamente il problema ed invia un segmento RTS per interrompere la connessione. Gaia ha dunque bisogno di iniziare una nuova connessione. 3.19 Il TCP ricevente alloca un buffer di dimensione fissa (la stessa dimensione del buffer allocato dal lato mittente). 0% pieno dimensione della finestra) dimensione della finestra) 25% pieno Nota: le frecce rosse mostrano dove viene letto il prossimo byte dal buffer 50% pieno 75% vuoto 100% vuoto dimensione della finestra) dimensione della finestra) dimensione della finestra) 50% vuoto dimensione della finestra) 100% pieno

Il programma applicativo dal lato del ricevente estrae i dati dal buffer, il che significa che non c è controllo del flusso dal TCP del ricevente verso il programma applicativo. I dati ricevuti dal TCP mittente rimangono nel buffer finché non sono consumati dal programma applicativo. La parte del buffer che è ancora vuota viene annunciata come valore della rwnd del TCP mittente (controllo del flusso). L immagine mostra un semplice esempio di come lo stato del buffer cambi. Abbiamo mostrato sia la rappresentazione lineare che circolare del buffer. Quest ultima mostra meglio la posizione dei dati che vengono letti dall applicazione. 3.20 Spieghiamo ogni caso separatamente: a. Quando un segmento ricevuto ha un numero di sequenza maggiore di R n, significa che i byte sono ricevuti fuori ordine. TCP memorizza i byte nella finestra di ricezione, ma manda un ACK con numero uguale a R n per aiutare la ritrasmissione rapida dei byte mancanti. Questo è un ACK duplicato perché il destinatario ha già inviato un ACK con numero Rn. L invio di un ACK duplicato è solo un indizio per il mittente che alcuni pacchetti sono arrivati fuori ordine. Se arrivano tre ACK duplicati, il mittente avvia la ritrasmissione rapida e rispedisce il pacchetto con numero di sequenza indicato dal riscontro. b. Quando arriva un segmento duplicato, il TCP ricevente scarta il pacchetto e invia un ACK che definisce il segmento atteso. Questo è anche un ACK duplicato che segnala al mittente che il timer può essere scaduto prematuramente. Ci si potrebbe chiedere come il destinatario possa sapere se l ACK duplicato è per un segmento fuori sequenza o per un segmento duplicato. Per avviare la ritrasmissione rapida, il mittente ha bisogno di ricevere tre ACK duplicati (quattro con lo stesso numero di sequenza); un solo ACK duplicato non causa l avvio della ritrasmissione rapida. 3.21 I dati dal processo client, 5400 bytes, possono essere divisi in sei parti (cinque parti da 980 byte e uno da 500 byte). Aggiunta l intestazione di 20 byte, abbiamo sei segmenti (cinque di 1000 byte e uno di 520 byte). I segmenti e gli ACK sono creati in base alla regola menzionata nel testo. La dimensione della finestra di congestione è incrementata di un MSS per ogni ACK ricevuto. Se seguiamo la crescita della cwnd, possiamo vedere che l andamento è esponenziale, ma la base diminuisce da 2 a 1.5 (2 0 = 1, 2 1 =2, 1.75 2 3, 1.60 3 4, 1.5 4 5).

Segmento 3.22 Di seguito si mostrano gli eventi e i valori. Le unità per la colonna ssthresh sono MSS. Per gli stati usiamo le seguenti abbreviazioni: slow start (SS), congestion avoidance (CA), e fast recovery (FR). Lo stato più a sinistra mostra lo stato corrente, quello più a destra il nuovo stato.

Stato Evento Stato 3.23 Secondo l algoritmo di Karn, dobbiamo ignorare il RTT per il primo segmento nel nostro calcolo perché è scaduto il timeout e il segmento è stato rispedito. Usando solo il secondo segmento, il calcolo è il seguente: RTT M = 23 6 = 17 ms RTT S = (1 0.2) RTT S + 0.2 RTT M = 14.6ms