Simulazione del traffico sulla linea ex-OMI/Rettorato
 

1.Oggetto e scopo della simulazione

Si  è cercato innanzitutto di riprodurre, con gli oggetti messi a disposizione dal simulatore, lo scenario reale costituito da:

• la LAN del Dipartimento di Informatica e Automazione, compreso il router per il collegamento verso l'esterno;
• la linea a 384Kb/s che collega il router in questione al Rettorato di Roma3;
• 4 host su altrettante LAN collegate direttamente al Rettorato da linee punto punto con velocità comprese tra 64Kb/s e 512Kb/s.

Per modellare la LAN del dipartimento abbiamo deciso di creare 8 nodi (rappresentativi di tutti gli host effettivamente presenti) collegati ad un router da linee punto punto a 10Mb/s con tempi di latenza pari a 5 us. Non si è scelto di utilizzare l'oggetto LAN fornito dal simulatore poichè nel NAM è stata riscontrata l'impossibilità di marcare con diversi colori i vari flussi di traffico, cosa che avrebbe pregiudicato l'intellegibilità dell'animazione. Ecco come si presenta nel NAM la topologia che abbiamo generato:
 

Sulla sinistra possiamo distinguere la LAN del dipartimento, con il router rappresentato dal nodo 4. Gli altri nodi implementano sorgenti di traffico di diverse tipologie:

• i nodi 0,1,2,3 rappresentano dei clients http;
• il nodo 7 rappresenta un server FTP;
• il nodo 9 rappresenta un host su cui è attiva una connessione Telnet;
• il nodo 11 rappresenta un server http.

Sulla destra osserviamo invece il router del rettorato, corrispondente al nodo 5, e gli altri host su LAN distinte e dislocate sempre nell'area dell'Università di Roma3. Il loro significato è il seguente:

• il nodo 6 rappresenta il server http cui fanno riferimento i clients 0,1,2,3;
• il nodo 8 rappresenta il client FTP che si connette con il nodo 7;
• il nodo 10 rappresenta l'altro estremo della connessione Telnet;
• il nodo 12 rappresenta un generico client http che chiama il server del DIA.

Si è cercato di attaccare agents di tipo FullTCP su tutti nodi della rete, ma questo si è rivelato impossibile per i nodi Http a causa di un presunto bug del simulatore.Per i nodi FTP si è invece deciso intenzionalmente di non usare il protocollo FullTCP perchè il simulatore avrebbe mostrato pacchetti di richiesta di connessione dal server verso il client, cosa quantomeno irrealistica. Per le suddette sorgenti abbiamo quindi utilizzato agents TCP one way.

Il nostro scopo è stato quello di simulare il traffico della LAN destinato all'esterno e di verificare le prestazioni della linea di collegamento con il rettorato al variare di alcuni parametri di interesse.Abbiamo quindi scritto 3 diversi file per descrivere altrettante situazioni di traffico.

2. Il modello del router

Il router presente sulla nostra LAN è un Cisco della serie 2500 con due interfacce attive: una verso Ethernet ed una verso la linea a 384Kb. I principali parametri di configurazione della macchina stati ricavati direttamente via Telnet, ma l'unico che è stato possibile impostare nella nostra simulazione  è la dimensione del buffer della coda di uscita sul link verso il Rettorato. Tale buffer consiste di 64 slots. Non è invece stato possibile impostare i tempi di processamento dei pacchetti (che peraltro dovrebbero essere poco influenti sui risultati della simulazione), né tantomeno una disciplina di gestione della coda simile a quella reale. Infatti, sebbene ns preveda varie discipline di gestione delle code, l'unica con cui si è riusciti a impostare la dimensione massima del buffer è quella di tipo DropTail (FIFO).

3. Il traffico in uscita prodotto dalla LAN del DIA

Abbiamo cercato di riprodurre una situazione di traffico relativa ad una generica ora diurna di un giorno feriale. Il tempo di simulazione è di 5 minuti.

Per modellare il volume di traffico ci siamo riferiti ai dati di monitoraggio del Centro Elaborazione Dati del Rettorato, disponibili sul sito : diamante.uniroma3.it/stat/193.205.139.1.21.html. Da questi dati è emerso che sulla linea ex-OMI/Rettorato transitano in media 3000-3500 bytes/s con picchi di 25000-30000 bytes/s; bisogna però considerare che nell'arco delle 24 ore in media solo per 14 ore c'è un utilizzo tale della LAN da produrre traffico rilevante in uscita.Quindi per la nostra simulazione il dato medio va moltipilcato per un fattore 24/14 = 1.7 , ottenendo così il valore di 5000 bytes/s. Nell'ipotesi (ragionevole, ma non ancora verificata) che i dati forniti dal Rettorato comprendano l'overhead del protocollo di livello 2 utilizzato sulla linea, e sapendo che tale overhead non viene considerato dal simulatore ns, abbiamo per sicurezza stimato un valore medio più basso e pari a 4000 bytes/s.

• traffico Http : per quanto riguarda i clients, i parametri su cui abbiamo agito sono stati il valor medio dell'intervallo di tempo tra due GET (estratto da una distribuzione poissoniana) e la dimensione media delle pagine richieste; dopo alcuni tentativi si sono scelti rispettivamente i valori di 0.05 sec (media su tutti i 4 clients, equivalente a 20 richieste al secondo) e 10KB di dimensione delle pagine; per quanto riguarda il server abbiamo utilizzato un valore medio calcolato su 20 giorni con i dati ottenuti direttamente dalla macchina: 7,8 sec di intervallo tra 2 richieste consecutive(pari a 0,127 richieste al secondo) e dimensione media delle pagine di 10KB.
• traffico FTP : nell'arco dei 5 minuti di simulazione abbiamo impostato 4 sessioni FTP (ricordiamo che il server è sulla nostra LAN mentre il client è all'esterno); i parametri che è stato possibile variare sono gli istanti di inizio e fine delle sessioni FTP (non è possibile controllare la quantità di dati da trasferire sebbene sia prevista una istruzione ad hoc); la durata delle singole sessioni varia tra 1,5 e 2 secondi.
• traffico Telnet : l'intervallo di tempo medio tra l'invio di 2 pacchetti Telnet consecutivi (estratto da una distribuzione esponenziale) è stato da noi posto uguale a 0.5 sec.

4.Gli oggetti monitorati

Le informazioni prodotte in uscita dal codice sorgente della nostra simulazione sono così suddivise:
 

Tutti questi dati sono stati ottenuti utilizzando l'oggetto QueueMonitor messo a disposizione dal simulatore, e sono stati registrati su dei trace file mediante semplici procedure record come spiegato nella pagina sul monitoraggio di code. Per visualizzare i grafici abbiamo utilizzato Xgraph con la consueta chiamata nella procedura finish.

Vai ai risultati della simulazione.