Eserciziario di Reti di Calcolatori
Università degli Studi di Padova, a.a. 2004-05, prof. Satta
Soluzione:
Un flusso tra processi viene più propriamente detto canale; un flusso è in generale un insieme di datagrammi che vanno da un host ad un altro seguendo il medesimo cammino nella rete.
a)Per un applicativo può essere sufficiente gestire un solo canale, o più canali verso un unico host, per esempio un utilità come FTP richiede la gestione di più canali verso un medesimo host, perciò in questo caso ha senso di parlare di un flusso dove ogni canale identifica una porta diversa.
b)Il calcolo di FlowLabel dovrebbe basarsi sugli indirizzi IP della sorgente e dell’host destinazione oltre alle loro porte, in questo modo sarebbe garantita l’unicità; si noti che per ogni quadrupla <IPsorg, PortSorg, IPdest, PortDest> può esistere più di un flusso perché più datagrammi possono essere inoltrati attraverso path differenti.
Soluzione:
TCP: feedback-based, window-based, host-centric.
a)host-centric, feedback-based, speed-based:
Invece di usare sliding window TCP dovrebbe implementare un controllo di velocità su i datagrammi che spedisce cioè deve limitare, se maggiore, la sua banda.
b)router-based, feedback-based:
In questo caso l’allocazione delle risorse può essere fatta dai router, in particolare i timeout possono essere controllati dai router, inoltre se il router è congestionato può informare l’host che spedisca di meno oppure che alcuni suo i pacchetti sono stati eliminati.
Soluzione:
Si considera di misurare il carico in un modo naturale: cioè in pacchetti.
Nel tratto A-R la banda è infinita, considerando che nella stessa tratta la latenza sia paragonabile a zero, il problema sorge solo nella tratta R-B. Il router ha una coda infinita perciò non c’è nessuna perdita di pacchetti.
Soluzione:
TCP Reno = AIMD + SlowStart (+ Jacobson’s CongestionThreeshold) + Fast retransmit + Fast recovery.
Una CongestionWindow > 2*RTT*Banda è molto improbabile che venga raggiunta anche con TCP Thaoe. Vediamo perché non viene raggiunta con Reno:
- Reno parte con slowstart, mettiamo che RTT è stato calcolato in modo affidabile dall’algoritmo di Jacobson/Karels, perciò già mentre stiamo spedendo 2*RTT*Banda pacchetti metà dei pacchetti vengono eliminati da qualche router sulla linea e non arrivando gli ACK: scade così un timer (assumiamo che non capitino occasioni in cui possa partire FastRetransmit).
Salvo
CongestionThreshold = CongestionWindow/2 = RTT*Banda
e non raggiungo quindi valori maggiori.
- Reno successivamente ad una nuova partenza con slowstart (ammettiamo che ci sia stato un timeout quindi non usa fast recovery) arriva quindi fino a CongetionThreshold successivamente utilizza una crescita AI che non gli permetterà mai di raggiungere CongestionWindow maggiori di 2*RTT*Banda.
- Se prendiamo in esame il caso in cui c’è una successiva partenza con FastRecovery, dovuta alla rilevazione di congestione da parte di Fast Retransmit, questa setta il valore di CongestionWindow a metà e riprende con AI, come nel caso precedente siamo immuni da raggiungere valori di CongestionWindow eccessive.
Soluzione:
Il seguente schema visualizza un esempio di congestione, tutti i router di questo esercizio con tre ingressi/uscite possono essere congestionati in un modo simile; il router R1 non può essere congestionato allo stesso modo perché ha due linee full-duplex con la stessa ampiezza di banda.
Soluzione:
Si usi la formula dell’equità a pagina 400.
Soluzione:
Fi è l’istante in cui termina la spedizione del pacchetto i-esimo di un singolo flusso in analisi.
PROPOSTA: Fi = (max(Fi-1, Ai) + Pi)/w
Soluzione:
Se abbiamo per esempio due flussi A e B, A ha un solo pkt il cui Fi e 5 mentre B ha due pkt che hanno Fi rispettivamente 10 e 15; viene quindi mandato prima il pkt di A, a questo punto si spedisce B nello stesso tempo arriva un pkt sul flusso A mettiamo con Ai = 7 e con Pi = 4, per questo viene calcolato Fi = 11. Successivamente viene prima spedito il pacchetto di A e poi quello che ancora all'istante iniziale era arrivato su B.
Soluzione:
Se e solo se i pkt vengono ricevuti nello stesso istante solo in successione diversa tutti i pkt di ogni flusso avranno Ai = 0 (Ai con valore locale alla coda).
Percio':
Quindi :
1 7 8 5 2 3 6 4
Soluzione:
costo = dimensione * tempo rimanente in coda
a) svantaggi: pacchetti piccoli riescono facilmente ad avere un basso costo e ad uscire velocemente dalla coda; pacchetti grandi hanno buone probabilità di essere eliminati soprattutto se arrivano in coda.
Soluzione:
Linea di collegamento 1Gbps con latenza di 100ms
File: 10MB
Finestra TCP: 1MB
Dimensione pacchetto: 1KB
IPOTESI: no congestione, no perdita pacchetti. (non scattano timer, non devo ritrasmettere: condizioni ideali)
a)
210 = 1024:
1 2 4 8 16 32 64 128 256 512 1024
Dopo 10 RTT la partenza lenta mi porta 1024 pacchetti da 1KB cioè ad 1MB che equivale alla finestra TCP. A questo punto CongestionWindow potrà si essere maggiore di AdvWin ma MAXWin viene scelta come min(CongestionWindow, AdvWin) perciò slowstart si ferma e la finestra si mantiene fissa.
b) Dopo questa partenza serviranno 9 RTT per trasmettere il resto dei 10MB (9MB mancano)
In totale servono 9+10 = 19RTT.
c)
tempo di trasferimento = 19 * 100ms = 1,9 sec
throughput = (10 * 2^20 * 8 ) bit / (1,9) sec = 42,1 Mbps
Viene quindi sfruttato il 4,21% della banda.