Capitolo 4
Valutazione sperimentale
Nei capitoli precedenti abbiamo cercato di dare una visione chiara ed esaustiva del problema passando in analisi tutte le varie fasi del lavoro svolto, arrivati a questo punto proponiamo alcune prove simulative che chiudono questo lavoro di ricerca.
4.1 Presentazione dello scenario
Lo scenario scelto per le prove finali è più complesso ed articolato rispetto a quelli visti fino ad ora, utili soltanto per la valutazione e la verifica del lavoro svolto.
Lo scenario proposto cerca di disegnare per quanto possibile una situazione reale in cui sono presenti alcuni switch su cui sono collegati utenti con i propri End-System che producono un traffico casuale formato sia da chiamate voce , video o connessioni Ftp.
La figura 44 rappresenta lo scenario creato con Opnet, questo è stato riprodotto usando sia il modulo che implementa il WFQ a livello 2 sia usando il modello standard presente in Opnet che riproduce lo scheduler FIFO
Lo scopo primario infatti è quello di simulare prima in situazione standard e poi con il nostro modulo; grazie al confronto dei risultati di questi due casi
vogliamo verificare se il nostro scheduler protegge la banda riservata al traffico scelto, in modo efficiente.
Figura 1. Scenario
Vediamo nel dettaglio come abbiamo impostato i flussi e qual’è la dinamica della simulazione: la struttura è formata da 2 rose di 9 End-System e 2 di 15 End-system, collegate rispettivamente allo switch_1, switch_2,switch_4 e switch_5.
Abbiamo creato 18 connessioni voce, 2 videoconferenze, 8 connessioni Ftp e 20 flussi di traffico dati di Background, tutti questi flussi partono dagli End-system e passando attraverso lo switch_3 arrivano allo switch_0 in modo tale da creare un collo di bottiglia all’uscita del primo switch.
Lo switch_0 è visto come un sink ovvero come un pozzo nel quale vanno a finire tutte le connessioni, nella realtà può essere comparato ad un gateway di uscita della rete LAN verso l’esterno; i flussi in uscita dal “sink” sono stati ripartiti in base alla classe di appartenenza sulle quattro macchine chiamate RX_n.
La macchina con nome RX_0 riceve i flussi relativi alle chiamate voce, queste connessioni sono quelle più sensibili ai ritardi per questo motivo hanno un maggior peso nella gestione delle code; devono avere una banda garantita e non superare mai una certa soglia di ritardo altrimenti la connessione voce risulta inutilizzabile.
La seconda macchina RX_1 raccoglie i flussi di video chiamata, anche questi dati sono molto sensibili al ritardo e alle perdite e per questo motivo la banda relativa alla trasmissione video è anch’essa tenuta di conto e la banda relativa è dimensionata in modo tale che i ritardi non superino certi valori.
Le altre due macchine RX_2 e RX_3 riguardano i flussi Ftp e quelli di Background, questi flussi non sono sensibili ai ritardi quindi la loro banda viene sotto dimensionata proprio per lasciare spazio alle trasmissioni delay sensitive; all’interno di queste due connessioni viene comunque dato un peso diverso in modo che le connessioni Ftp, anche se in numero minore, abbiano una banda garantita superiore rispetto al traffico di Background. Nel caso di scheduler FIFO i throughput dei vari flussi rimane proporzionale alla quantità dei pacchetti inviati sulla rete quindi non è strano che nella simulazione standard all’uscita dello switch il flusso delle
chiamate voce sia maggiore delle altre connessioni ma questo non implica necessariamente che sia protetto.
Il flusso dati in questo caso è solo proporzionale alla quantità di pacchetti inviati in rete, la trasmissione voce risulta ritardata perché la parte di banda assegnata dallo scheduler FIFO è comunque minore di quella che effettivamente si utilizzerebbe per trasmettere la totalità dei dati.
Allo stesso modo possiamo ragionare per le connessioni Ftp e di Background, infatti, anche in questo caso le bande sono decise in modo proporzionale al numero di dati, di quel tipo, presenti in rete, ma nel nostro caso vogliamo che le trasmissioni Ftp abbiano la precedenza su quelle di Background anche se la massa dei dati risulta invertita, per fare questo dobbiamo assegnare un peso maggiore alla banda che gestisce quel tipo di traffico in modo che sia superiore a quello riservato per il Background.
In questo caso quindi abbiamo un’inversione delle capacità dei flussi rispetto allo scheduler tradizionale.
4.2 Descrizione dei flussi
Vediamo flusso per flusso come sono stati caratterizzati e gestiti i dati all’interno dello scenario, facciamo un rapido riepilogo di come sono impostati i flussi nell’application configuration e i profili nel profile configuration.
4.2.1 Chiamate voce
1 chiamata voce con codec G.711 sulla linea di trasmissione produce un traffico dati pari a 172 Kbit/sec.
18*172 Kbit/sec = 3096000 bit/sec
Tutti questi flussi partono simultaneamente al tempo 3 secondi.
4.2.2 Chiamate video
1 chiamata video con impostazioni del tipo 10 frame/sec
128x120 PixelÆ CONST (17280)
produce un traffico sul link di 207140 Byte/sec se produciamo 2 chiamate simultanee arriviamo a
2*207140*8 = 3314240 bit/sec
Tutti questi flussi partono simultaneamente al tempo 6 secondi.
4.2.3 Flussi Ftp
1 flusso Ftp produce un traffico medio di 41453 Byte/sec se produciamo 8 flussi simultanei arriviamo a
41453*8*8 = 2652992 bit/sec
Tutti questi flussi partono simultaneamente al tempo 9 secondi.
4.2.4 Flussi di Background
1 flusso casuale di back round produce un traffico medio di 21000 Byte/sec se produciamo 20 flussi simultanei arriviamo a
Tutti questi flussi partono simultaneamente al tempo 12 secondi.
Alla fine dei conti facendo la somma di tutti i dati che circolano in rete vediamo che la somma totale che attraversa lo switch_0 risulta essere
3096000 bit/sec + 3314240 bit/sec + 2652992 bit/sec +
3360000 bit/sec = 12423232 bit/sec
quindi possiamo vedere che il flusso totale risulta maggiore di 12 Mbit/sec e dato che i link sono a 10 Mbit/sec abbiamo raggiunto il nostro scopo e cioè quello di creare un collo di bottiglia.
4.3 Scelta dei pesi
Come già introdotto precedentemente la scelta dei valori da assegnare ai vari flussi è un’operazione molto importante e delicata vediamo nel dettaglio come abbiamo preso questa decisione.
Il traffico delay sensitive è quello prodotto dalla chiamata voce e dalla video conferenza quindi il nostro scopo principale è quello di proteggere questi due flussi con un banda garantita in modo tale che i pacchetti appartenenti a questa categoria stazionino meno possibile all’interno della coda dello switch.
In una rete di questo genere abbiamo deciso di offrire una banda garantita alle chiamate voce con un massimo di 18 connessioni simultanee quindi dato che questo tipo di traffico produce al massimo una massa dati che si
attesta intorno ai 3.1 Mbit/sec di traffico abbiamo deciso di riservare 3.2 Mbit/sec di banda solo per questo tipo di connessione.
La scelta è stata fatta per eccesso dato che i valori sono tutti medi e quindi la possibilità di burst è alta, le oscillazioni sono presenti in ogni momento della trasmissione e la scelta del valore per eccesso è basata su questo criterio.
Allo stesso modo abbiamo ragionato con la trasmissione video, dato che in questo caso il flusso è molto più pesante abbiamo deciso di garantire la banda a 2 connessioni video simultanee, quindi dato che queste connessioni producono un flusso dati pari a 3.32 Mbit/sec, abbiamo deciso di riservare 3.4 Mbit/sec di banda per questo tipo di connessione.
La banda rimanente che può essere suddivisa tra le altre due categorie di flusso risulta essere di 3 Mbit/sec sicuramente non sufficiente per garantire il passaggio di tutti i pacchetti appartenenti al flusso Ftp e di Background che nel totale producono oltre 6 Mbit/sec.
La scelta è fatta in funzione dell’importanza che i flussi hanno per la nostra rete, in particolare ci interessa, come accennato precedentemente, che il flusso Ftp non venga completamente oscurato dal traffico di Background, dato che quest’ultimo risulta essere un terzo più grande dell’altro, in una condizione di scheduler FIFO il throughput in uscita sarebbe diviso in modo proporzionale ai pacchetti creati, in questo caso voglio invece che la situazione sia invertita e che il flusso Ftp abbia a disposizione 2 dei 3 Mbit/sec di banda rimanente.
Anche se la banda assegnata è sempre minore dell’effettivo traffico dati prodotto sicuramente per la connessione Ftp le cose andranno meglio rispetto al caso standard.
La scelta fatta per i pesi della connessione voce e video sembra una scelta inefficiente dato che riserviamo più banda del dovuto a flussi che ne
producono meno e lasciamo sottodimensionato la banda per quelli che producono molto traffico; in realtà non è così dato che la banda destinata ai vari flussi non rimane inaccessibile, anzi se uno dei flussi più importanti dovesse venire a mancare la banda in avanzo verrebbe ridistribuita in base ai pesi sulle altre connessioni, allo stesso modo se le connessioni voce/video dovessero per un certo tempo produrre meno dati della banda a loro assegnata i flussi a peso inferiore ne guadagnerebbero immediatamente.
4.4 Risultati
Andiamo ora ad analizzare i risultati ottenuti tramite le simulazioni e analizziamoli per verificare che tutte le ipotesi siano verificate e discutere le migliorie del modello implementato rispetto all’originale, questo paragrafo sarà diviso in tre parti per rendere più chiara la comprensione dei risultati e capirne meglio il confronto.
4.4.1 FIFO
Il primo grafico di figura 45 rappresenta il throughput all’uscita dello switch_0, quello che abbiamo definito “Sink”, i grafici sono stati sovrapposti e mediati per una migliore comprensione della situazione.
Come detto precedentemente i flussi entrano a tempi diversi e questo è riscontrabile nel grafico, il primo flusso (blu) è il traffico voce, il secondo (rosso) è il traffico video, il terzo (verde) è il traffico Ftp mentre l’ultimo (celeste) rappresenta il traffico di Background.
Quando i primi 3 flussi entrano generano un traffico che risulta minore della capacità del link e di conseguenza i flussi si stabilizzano ad un valore pari al
massimo dei dati trasmessi, come si vede i flussi si stabilizzano inizialmente su di un valore pari rispettivamente a
Blu Æ 3096000 bit/sec
Rosso Æ 3314240 bit/sec
Verde Æ 2652992 bit/sec
La situazione cambia quando al tempo 12 sec parte anche l’ultimo flusso che produce un traffico pari a 3360000 bit/sec, l’ingresso di questo ultimo flusso provoca un assestamento di tutti i throughput in uscita dal link che a questo punto risulta sottodimensionato per il traffico in ingresso e crea un collo di bottiglia.
Figura 3. Ritardi End-to-end
Lo scheduler FIFO fa si che all’uscita dello switch i flussi siano proporzionali al traffico in ingresso, infatti come si può vedere dalla figura i flussi si stabilizzano ad un livello proporzionale ai dati prodotti e non in base all’importanza del traffico.
Questa gestione del traffico FIFO risulta sicuramente equa in quanto tutte le sorgenti sono trattate allo stesso modo ma appena si supera la capacità del link i pacchetti iniziano ad accumulare ritardi e quindi le trasmissioni voce/video risultano impossibili.
Nel grafico di figura 46 è stato riportato il ritardo End-to-end dei pacchetti nella rete, i ritardi accumulati sono tutti uguali in quanto i dati vengono trattati tutti allo stesso modo quindi nello switch “collo di bottiglia” i pacchetti fanno parte tutti della stessa coda.
Il ritardo inizia a crescere nel momento in cui entra l’ultimo flusso infatti possiamo vedere dal grafico che fino a quel momento i ritardi sono molto bassi e vicini allo zero dato che non abbiamo problemi di congestione, dal momento in cui il link non riesce a servire tutto il traffico dati il ritardo cresce enormemente e in pochissimo tempo.
Possiamo notare che in 6 secondi di attività di rete il ritardo raggiunge 1.3 secondi, la situazione è già congestionata ed ingestibile a questo livello, ma se la simulazione dovesse continuare ci renderemmo presto conto che i ritardi andrebbero ad aumentare sempre di più.
Vediamo per completezza il valore del delay jitter riscontrato in questo scenario in modo poi da confrontarlo con quello rilevato nel caso WFQ. Il grafico riportato di seguito mostra che anche questo importante valore, utile per il dimensionamento dei nodi, cresce in modo veloce dopo che la rete viene portata a saturazione e non trova un valore accettabile su cui stabilizzarsi.
Figura 4. Jitter
Vediamo a questo punto quale è la disponibilità di banda per le singole applicazioni Ftp e di Background, in particolare andiamo a graficare i flussi dati presenti nei link in entrambe le direzioni in modo da vedere il calo di prestazione nel caso di collo di bottiglia.
Nel grafico di figura 48 viene riportato il flusso dati presente in un singolo link collegato ad una trasmissione Ftp, è possibile vedere il calo delle prestazioni nel momento in cui la rete entra in congestione.
Il flusso dati nelle due direzioni è impostato per essere identico quindi la differenza tra i due flussi è dovuta alla limitata capacità trasmissiva della rete.
Figura 5. Throughput Ftp
Vediamo anche come si abbassa il flusso dati relativo ad un link che trasporta dati di Background, il meccanismo è lo stesso il link in una direzione marca la capacità effettiva che avrebbe quel flusso mentre nell’altra direzione le limitate capacità della rete diminuiscono il passaggio dei dati abbassando il throughput.
Figura 6. Throughput Background
4.4.2 WFQ
Vediamo adesso come si modifica la situazione se all’interno degli switch attiviamo il modulo WFQ e le postazioni inviano pacchetti con Tag in base al tipo di traffico prodotto inserendo, nel campo tag priority del pacchetto ethernet, il valore relativo alla classe di traffico.
Le impostazioni dei flussi in quanto a tempi di ingresso e data rate sono rimasti identici lo scenario è esattamente lo stesso, le connessioni
voce/video utilizzano gli stessi codec, i link sono esattamente gli stessi; la situazione è identica.
La grafico di figura 50 è analogo a quello di figura 45, viene cioè rappresentato il throughput all’uscita dello switch_0 ovvero la macchina che produce il collo di bottiglia.
Come possiamo vedere i risultati sono molto diversi.
Il flusso voce,video (blu,rosso) si stabilizzano al livello massimo immediatamente dato che la rete inizialmente risulta scarica ma la cosa interessante è che quando entra l’ultimo, quindi la rete subisce una congestione, i flussi non perdono la loro banda ma restano costanti sulla stessa banda fino alla fine della simulazione.
I vari pacchetti hanno una banda riservata quindi, se il traffico dati di quella specifica classe non supera la banda assegnata, non si crea congestione per quel flusso; nel nostro caso il valore del traffico dati voce/video risulta inferiore alla banda assegnata per quelle classi mentre per il traffico Ftp la banda risulta sotto dimensionata ed è per questo che assistiamo ad un assestamento della banda per il terzo flusso (verde).
L’ultimo flusso relativo al traffico di Background che inizia a trasmettere dopo 12 secondi si stabilizza ad 1 Mbit/sec senza oscillazioni dato che è quella la sua banda riservata e le altre connessioni occupano già il resto del link.
Vediamo adesso i ritardi dei pacchetti che abbiamo riscontrato nella rete nel caso WFQ, in questo caso dobbiamo separare i grafici in funzione dei pesi delle code dato che in funzione della classe di appartenenza i pacchetti stazionano un tempo diverso all’interno della loro coda.
La figura 51 mostra l’andamento nel tempo dei ritardi End-to-end accumulati dai pacchetti nel percorrere la rete, possiamo vedere che al tempo 12 sec abbiamo un’impennata del ritardo, questo è dovuto all’ingresso nella rete del flusso che satura la connessione; notiamo inoltre che subito dopo un periodo di assestamento il ritardo si stabilizza di nuovo a valori molto bassi, sicuramente sotto la soglia massima dei 200 msec, valore oltre il quale la connessione voce risulta degradata o addirittura inutilizzabile.
Figura 8. Ritardo End-to-end Voce
Associamo al ritardo il delay jitter dei pacchetti riscontrato nella rete simulata, in questo caso come è facile vedere nel grafico riportato di seguito la variazione del ritardo è minima e ampliamente sopportata dalle applicazioni anche dopo la congestione della rete.
Figura 9. Jitter voce
Allo stesso modo passiamo in analisi i risultati riscontrati sui ritardi End-to-end della connessione video, facciamo per questo riferimento alla figura 53. Anche in questo caso vediamo che i valori dei ritardi si attestano su valori molto bassi, dopo un periodo di assestamento il valore inizia ad oscillare intorno a 0.05 secondi.
Figura 10. Ritardo End-to-end Video
Questi valori sono accettabili per una video conferenza, non producono cioè degradazione della connessione e allo stesso modo il valore del jitter dei pacchetti rimane di molto sotto le soglie.
Figura 11. Jitter video
Il terzo grafico, presentato in figura 55, rappresenta i ritardi dei pacchetti della classe Ftp che sono relativi alla terza coda che ha un peso tale da riservare 2 Mbit/sec di banda.
Come vediamo il valore del ritardo è molto maggiore rispetto alle connessioni viste precedentemente e va a crescere, infatti il flusso dati di questa classe è maggiore della banda riservata e quindi questo risultato è plausibile.
Figura 12. Ritardo End-to-end Ftp
Il traffico dati prodotto da questa classe è circa 2.6 Mbit/sec; nel caso di scheduler FIFO la parte di banda assegnata a questa connessione risulta essere circa 2.1 Mbit/sec (figura 45), quindi molto simile a quella assegnata dallo scheduler WFQ di conseguenza possiamo notare che i ritardi sono molto simili. (Cfr. figura 46)
Questa scelta è stata fatta per non appesantire troppo le connessioni Ftp e assicurare delle prestazioni accettabili per questi flussi, ovviamente questo implica necessariamente che una qualche connessione deve essere
sacrificata, nel caso nostro abbiamo deciso di ridurre molto la banda relativa per le connessioni di Background.
Figura 13. Ritardo End-to-end Background
Vediamo a questo proposito il grafico di figura 56 che presenta i ritardi relativi ai dati di Background, come si può vedere dal grafico i ritardi salgono molto velocemente senza stabilizzarsi dato che, a fronte di una banda riservata di 1 Mbit/sec, i dati prodotti superano i 3 Mbit/sec.
Vediamo a questo punto quale è la disponibilità di banda per le singole applicazioni Ftp e di Background come visto precedentemente anche per lo scenario con lo scheduler FIFO.
Figura 14. Throughput Ftp
Nel grafico di figura 57 viene riportato il flusso dati presente in un singolo link collegato ad una trasmissione Ftp, è possibile vedere il calo delle prestazioni nel momento in cui la rete entra in congestione ed il calo è paragonabile con quello avvenuto con lo scheduler FIFO in quanto come già accennato precedentemente la banda riservata è simile a quella offerta nello scenario precedente.
Figura 15. Throughput Background
Come possiamo vedere nella figura precedente il calo del traffico dati che si ha nella direzione in cui ho saturazione della rete è notevole ma se la confrontiamo con quella dello scheduler FIFO ci rendiamo conto che questa classe di traffico è quella che risente più di tutte dello scheduler WFQ, risulta cioè quella più penalizzata.
E’ facile rendersi conto di questo fatto andando confrontare il grafico di figura 58 con quello di figura 49, è palese la differenza nel calo della capacità trasmissiva del canale.
4.4.3 Confronto
A fronte di questi risultati possiamo affermare che lo scheduler WFQ ci permette di proteggere efficacemente i dati più importanti e ci permette di dare vita a trasmissioni video/voce anche su link che presentano congestione e che non sarebbero utilizzabili con lo scheduler FIFO per i troppi ritardi accumulati dai pacchetti.
La scelta dei pesi da impostare negli switch è molto importante e deve essere fatta con cautela dato che una scelta poco saggia dei pesi potrebbe dare vita a situazioni non efficienti ed eque per tutti gli utilizzatori della rete.
