Ripasso stop and wait: prima di inviare un alto pacchetto la sorgente attende prima l'ACK per il pacchetto precedente.

Dobbiamo sapere in quanti pacchetti viene suddiviso il dato della sorgente:
, ovvero in 6 pacchetti in cui l'ultimo ha un payload di (ottenuto sottraendo ripetutamente a ) a cui dobbiamo sommare l'header di per un pacchetto di dimensione

La sorgente deve inviare 5 pacchetti: calcoliamo il tempo per la trasmissione e la propagazione di un solo pacchetto.
La velocità di propagazione è fornita nella nota alla fine del quesito ed è .
Calcoliamo lo stesso tempo anche per trasmettere l'ultimo pacchetto che è più piccolo:

Adesso calcoliamo il tempo per la trasmissione di un ACK.

Il tempo per la trasmissione di tutti i pacchetti è la somma dei ritardi di trasmissione per tutti i pacchetti: , a cui dobbiamo sommare il tempo per propagare ogni pacchetto (no flusso continuo: stop and wait): , a cui dobbiamo sommare il tempo per trasmettere tutti gli ACK: a cui dobbiamo sommare il tempo per propagare tali ACK: .

Il throughput medio è il numero di bit che vengono trasmessi nel tempo totale in cui è stata effettuata la trasmissione, in il nodo A ha inviato , visto che il problema vuole il risultato in dobbiamo portare in : : L'efficienza è il rapporto tra quanto si trasmette rispetto alla capacità del collegamento:

• VERS: versione del protocollo IP (v4, v6)
• HLEN: lunghezza dell'header in word da 32 bit
• SERVICE TYPE: tipo di servizio offerto da IP
• TOTAL LENGTH: lunghezza totale del pacchetto inclusi header e dati
• IDENTIFICATION: ID condiviso tra tutti i frammenti in caso di frammentazione
• FLAGS: tre bit, di cui l'ultimo è il more fragment che indica se il frammento è l'ultimo per un certo datagramma o no. Se è posto a 0 è l'ultimo altrimenti no
• FRAGMENT OFFSET: posizione del frammento all'interno del datagramma originale espresso in ottetti di byte
• TTL: massimo numero di router attraversabili prima che il datagramma venga scartato
• PROTOCOL: codice di protocollo del segmento che sta incapsulando il datagramma (esempio TCP)
• HEADER CHECKSUM: calcolati dal mittente e utilizzati dal destinatario per verificare l'integrità dell'header
• SRC IP: IP che ha generato il datagramma
• DEST IP: IP cui il datagramma è diretto
• IP OPTIONS: opzioni aggiuntive
• PADDING: utilizzato per assicurarsi che la dimensione dell'header sia fatto di multipli di 32 bit.

Vedi soluzione qui

1. [1,6] e [23,26]
2. [6,16] e [17,22]
3. La perdita viene rilevata da un triplice ACK duplicato, la finestra viene dimezzata e le viene aggiunto 3 (che sta per i tre ACK duplicati), infatti la finestra passa da un dimensione di 42, a
4. La perdita viene rilevata da un timeout, evento molto grave, che fa rientrare TCP nella fase di slow start
5. Il valore iniziale di ssthresh è 32, dopo il quale si entra in congestion avoidance
6. Dopo il 18-esimo turno è 21, la dimensione della finestra viene impostata a , NON c'entra con il valore di ssthresh.
7. Dopo il 24-esimo turno è (non viene aggiunto 3, perché si è verificato timeout)
8. I segmenti vengono spediti in questo modo: in particolare prima di aggiungere è il 70-esimo pacchetto non è ancora stato spedito, il che vuol dire che viene spedito proprio nel settimo turno
9. Se si verificasse una perdita dopo il 26-esimo turno per un triplice ACK duplicato la finestra viene impostata a .
10. TCP Tahoe non ha la fase di fast recovery, ma implementa solo fast retransmit (che non c'entra con fast recovery) e ricomincia direttamente da slow start, quindi quando si verifica la perdita al turno 16, al turno 17 la finestra avrà dimensione 1, poi 2, poi 4, poi 8, poi 16, in totale verrebbero spediti: segmenti.

Sono state unite le reti che hanno lo stesso next hop di destinazione e prefissi di rete simili unibili in una qualche subnet comune.

Per la risoluzione di questo esercizio conviene scrivere i vettori iniziali per tutti i nodi e simulare delle condivisioni tra tutti i nodi (vicini) finché l'algoritmo non converge.

Quando converge il nodo il vettore di distanza per x è: (13,5,7,0,5)
Il vettore iniziale per w invece è: (inf,5,0,7,inf)

Per stabilire il tempo minimo per distribuire il file a tutti dobbiamo considerare che il server distribuisce il file ad ogni peer, quindi è come se distribuisse volte il file, dove che è il numero di peer. E dobbiamo considerare anche il tempo necessario affinché il peer con velocità più lenta () in download scarica il file. Di questi dobbiamo scegliere il massimo valore, che determinerà il tempo minimo affinché venga distribuito il file a tutti:
Il massimo è

Il collo di bottiglia è dato dal server. Il motivo è che affinché un client cominci a scaricare il file, esso deve essere disponibile sul canale.

In una architettura P2P dobbiamo tenere conto del fatto che il server invia il file una volta sola nella comunità P2P e non volte. Dobbiamo sempre tenere conto del tempo che impiega il peer più lento a scaricarlo. Infine, allo stesso modo di prima, è come se venissero inviati file, ma stavolta la velocità utilizzata per la condivisione è la somma di tutte le velocità di upload . Tra questi dobbiamo scegliere il massimo:

il secondo fattore lo abbiamo calcolato prima: .
Per l'ultimo fattore abbiamo che: Il cui massimo è

Il collo di bottiglia è dato dal client più lento in download, in particolare .

1. Indiretta (bisogna passare dal roouter)
2. Confrontando l'indirizzo della rete del destinatario, con l'indirizzo della sua rete, se le reti sono diverse allora si verifica consegna indiretta. La netmask viene utilizzata per separare dall'indirizzo la parte di rete.
3. 111.111.111.111
4. 222.222.222.222
5. Il router
6. L'host sa che quando deve inviare un pacchetto a un host esterno alla sua rete, deve contattare il default gateway, in questo caso il router
7. 74:29:9C:E8:FF:55
8. E6:E9:00:17:BB:4B

1. gaia.cs.umass.edu/cs453/index.html
2. 1.1
3. Persistente
4. Non è specificato
5. Mozzilla, per consentire al server di personalizzare le risposte in base alla caratteristiche del browser dell'utente.