3.2 Validazione emulatore wireless e planetlab
3.2.3 Validazione dell’emulatore wireless
La parte che si occupa di emulare un link wireless `e un componente del tutto nuovo, quindi ha bisogno di essere provato accuratamente prima di essere introdotto nell’emulatore. L’obiettivo `e quello di validare quanto il nuovo componente riesca a riprodurre il comportamento di una rete wireless reale.
I test di validazione sono stati effettuati in una rete wireless reale, in diverse condizioni operative. Gli stessi esperimenti sono stati ripetuti configurando l’emulatore in modo da modellare la rete wireless originale. Dal momento che l’emulatore riproduce gli effetti del canale la principale metrica utilizzata sar `a il throughput che pu `o essere raggiunto sul link (reale o emulato).
In generale, i test hanno coinvolto una stazione (STA) e un Access Point (AP) vicini (Figura 3.6), e un server connesso all’AP configurato in modo tale da essere l’endpoint della comunicazione. Un nodo monitor viene utilizzato per collezionare eventuali tracce di eventi interessanti sul canale wireless, come ritardi par- ticolari tra i pacchetti, ritrasmissioni . . . e per aiutare ad individuare le possibili cause in caso di discrepanza tra i valori reali e quelli simulati.
L’incertezza sulle condizioni della rete, in particolare la presenza di stazioni interferenti non note, rende difficile ottenere un match perfetto tra i risultati emulati e quelli ottenuti nel mondo reale. Tuttavia ci sono dei
0
0.2
0.4
0.6
0.8
1
0.1
1
10
100
CDF
Ping response time (msec)
Figura 3.5: Distribuzione dei tempi di risposta del ping tra coppie di nodi PlanetLab colocati.
Figura 3.6: Lo scenario degli esperimenti.
casi molto semplici in cui i risultati dovrebbero essere coincidenti. Uno di questi casi si ha quando un nodo trasmette uno stream unidirezionale di pacchetti su un canale altrimenti idle. Mentre non c’ `e garanzia che un canale sia esente da fenomeni di interferenza, eseguire tanti piccoli esperimenti (5-10 s) su diversi canali a diverse ore del giorno pu `o fornire una probabilit `a ragionevole che almeno alcuni di questi esperimenti siano stati eseguiti in assenza di interferenza.
Un primo insieme di esperimenti `e stato eseguito per misurare il massimo throughput raggiunto con diversi 802.11b e 802.11g rate, e poi verificare se l’emulatore `e in grado di riprodurne il comportamento. L’Access Point `e stato configurato in modo da operare ad un rate fisso, dopo di ci `o `e stato inviato un flusso unidirezionale di pacchetti UDP di dimensioni massime, dal server alla stazione, utilizzandoiperf[40]. La scelta di utilizzare pacchetti UDP ha permesso di evitare l’interferenza legata agli acknowledgements TCP che sono inviati nel senso opposto.
In Figura 3.7 `e rappresentata la distribuzione del throughput ottenuto in una serie di esperimenti (da 50 a 200) a diversi rate. I diversi valori ottenuti sono dovuti ad occasionali interferenze sul canale. La colonna etichettata con Real in Tabella 3.3 riporta la massima, la media e la deviazione standard per queste misure. I valori massimi dovrebbero rappresentare la massima capacit `a del canale ad ogni rate, al netto di tutti gli
overhead, e rappresenta il nostro target per quello che riguarda i risultati dell’emulazione.
0
0.2
0.4
0.6
0.8
1
0
5
10
15
20
25
30
35
CDF
Throughput (Mbit/s)
54
36
24
18
11
5.5
2
1
Figura 3.7: Throughput CDF per differenti rate, in Mbit/s.
Gli esperimenti emulati sono stati fatto eseguendo lo stesso test su un link emulato. Per il profilo di ritardo (Paragrafo 1.3.2), le misure fanno vedere che il nostro Access Point utilizza dei backoff casuali utilizzando solo 16 slot (al posto dei 32 definiti dallo standard) quindi il nostro profilo `e stato configurato tenendo conto di questa particolarit `a. Inoltre `e stato considerato anche l’effetto dei beacons (con occorrenze di 10 volte al secondo, e con un consumo di circa 1.14 ms nella nostra rete) che hanno consumato circa l’1% del tempo a disposizione per la comunicazione, e sono stati modellati con un equivalente valore di netload. Il parametro collision `e stato impostato a 0, perch ´e negli esperimenti effettuati non c’ `e stata interferenza tra i vari beacons ed i pacchetti di dati (entrambi provengono dallo stesso device).
In Tabella 3.3 viene confrontato il throughput in una rete reale e negli esperimenti emulati. Per quando `e stato detto finora occorre confrontare i valori massimi di entrambe le colonne, in questo caso vedremo che c’ `e un match di valori. Naturalmente, questi risultati ci dicono solo che possiamo riprodurre in modo realistico una particolare configurazione del sistema, ma allo stesso tempo fanno emergere come gli esperimenti su reti reali presentano una variabilit `a elevata, dovuta alle impredicibili condizioni del canale.
Nominal Real Emulator
Rate Max Avg sd Max Avg sd 54000 28390 27970 281.4 28570 28500 46.6 11000 7879 7788 68.7 7831 7806 27.3 5500 4455 4377 85.4 4405 4400 3.4 2000 1767 1737 39.2 1772 1771 0.548 1000 894 881 16.7 900 899 0.448
Tabella 3.3: Throughput reale ed emulato per traffico UDP unidirezionale alle velicit `a 802.11b e 802.11g. I rate sono in Kbit/s.
Modello del traffico in competizione
Per analizzare l’effetto del traffico concorrente e capire come pu `o essere modellato, sono state fatte delle misure del throughput di un flusso TCP unidirezionale. In questo caso il traffico nella direzione opposta non solo avrebbe consumato del tempo occupando il canale, ma avrebbe anche generato un certo numero di collisioni dal momento che i dati e gli ACK sono sincronizzati tra loro. La presenza del valore di backoff random riduce la probabilit `a di collisione, ma non la elimina del tutto. Questa probabilit `a dipende fortemente dal numero di stazioni attive sul canale, dal pattern specifico del traffico e dal carico della rete [16, 47]. Il numero di slotCW utilizzato per il backoff random introduce un fattoreφ/CW nella probabilit `a di avere una collisione, ma per ottenere un valore pi `u aderente alla realt `a occorre procedere in modo sperimentale.
In Tabella 3.4 viene confrontato il valore del throughput di un flusso TCP unidirezionale di un link wireless reale a 11Mbps con un link emulato, utilizzando diversi valori per il parametro di collisione. Come detto precedentemente i dispositivi utilizzati utilizzano un valore diCW = 15quindi per verificare l’aderenza al modello il valore dei parametri di collisione `e stato cercato partendo da1/CW. Impostando tale valore a 0 si ottiene naturalmente una stima in eccesso della larghezza di banda disponibile. Nei test condotti si ha che un fattore vicino a1/CWmodella il canale in modo abbastanza soddisfacente. A causa delle diverse condizioni non `e possibile effettuare un confronto diretto tra i risultati riportati in reti sature [16] o non sature [47], tuttavia questi valori rappresentano un buon punto di partenza nella valutazione dell’impatto della collisione di pacchetti.
Scenario Throughput (Kbit/s) (real or emulated) Max Avg sd
real 5729 5681 32.0 em, coll = 0 6266 6237 10.9 em, coll = 0.04 5936 5876 21.4 em, coll = 0.06 5733 5692 19.6 em, coll = 0.07 5657 5601 26.3 em, coll = 0.08 5546 5520 21.4
Tabella 3.4: Throughput reale ed emulato, utilizzando un rate nominale di 11Mbps. I test eseguiti su un ambiente emulato sono stati configurati con diversi valori per il parametro di collisione, come indicato nella prima colonna.
Per effettuare degli esperimenti su nuovi protocolli e sistemi di comunicazioni vengono in genere utilizzate delle reti di computer, formate da una o pi `u macchine usate come “nodi”, e da degli strumenti software di forwarding dei pacchetti. Molti di questi prototipi sono stati sviluppati su sistemi operativi general purpose, in grado di fornire un ambiente comodo per effettuare gli esperimenti. A volte, il livello delle prestazioni e la maturit `a raggiunta dal codice, hanno permesso a quest’ultimo di essere integrato nei sistemi di produzione.
Tuttavia le prestazioni purpose relative alla elaborazione dei pacchetti raggiungibili su sistemi operativi general purpose `e uno o due ordini di grandezza inferiore ai corrispettivi strumenti software dedicati, e ci `o accade in modo particolare quando sono coinvolte reti ad alta velocit `a (1..10 Gbit/s).
Le operazioni di packet I/O5tendono ad essere uno dei passi pi `u costosi nell’intero processo di elabo- razione del pacchetto. Questo `e vero sia che il thread che processa il pacchetto si trovi in user space che in kernel space.
Molte applicazioni per `o riescono a superare queste difficolt `a, evitanto di utilizzare le routine del sistema operativo, e passando direttamente il controllo all’hardware. Ci `o fa pensare che `e possibile realizzare del software in grado di manipolare i pacchetti con delle prestazioni migliori. In letteratura diversi progetti di ricerca [33, 38, 41] hanno affrontato l’argomento.
Il recente sviluppo di un nuovo framework chiamato netmap[58], riduce in modo significativo il costo dovuto al packet I/O su sistemi operativi general purpose. Un primo obiettivo di questo studio `e stato quello di capire se le applicazioni che fanno un intenso uso del forward dei pacchetti (software routers, firewalls, NAT, etc.) possano essere resi pi `u performanti semplicemente rimpiazzando le routine di I/O esistenti con una versione pi `u efficiente. Inoltre `e anche interessante capire lo sforzo necessario in termini di codice da modificare, necessario all’implementazione di una nuova infrastruttura di I/O.
Idealmente, vorremmo far girare le nostre applicazioni su un sistema operativo “migliorato”, il quale non modifichi l’interfaccia delle funzioni di packet I/O verso lo user-space, e che abbia prestazioni complessive migliori, il tutto in modo il pi `u possibile trasparente alle applicazioni stesse.
Di seguito la nostra esperienza sull’argomento, la quale `e estremamente incoraggiante. Sono presen- tate, come case studies principali, le due applicazioni: un sistema software di packet forwarding, chiamato OpenvSwitch [54], e la versione user-space di un router modulare, chiamato Click [41].
Entrambe le applicazioni usano la librerialibpcap [4] per l’accesso al packet I/O. In entrambi i casi `e stato possibile ottenere un enorme incremento di prestazioni semplicemente sostituendo lalibpcap stan- dard con una nostra versione modificata che usa netmap (si veda la sezione 3.5). Per OpenvSwitch si `e passati da 780 Kpps6a 3.0 Mpps; mentre per Click si `e passati da 490 Kpps a 3.95 Mpps7. Ad ogni modo, il
fatto di ottenere notevoli incrementi delle prestazioni, ha richiesto un certo, seppur limitato, sforzo di program- mazione. Infatti non sempre il collo di bottiglia dovuto al packet I/O `e l’unico responsabile di performance poco significative, ma molto spesso tale collo di bottiglia nasconde perdite di prestazioni importanti in altre componenti.
Per esempio, per OpenvSwitch le prestazioni originali si aggiravano sui 65 Kpps. Come descritto nel Paragrafo 3.6.1, sono state necessarie alcune modifiche all’applicazione per sfruttare i benefici di una libreria di I/O pi `u veloce. Nel caso di Click la situazione `e stata simile: la sola sostituzione della libreria di I/O ha dato un incremento di “soli” 1.3 Mpps, modesto se confrontato con il risultato ottenuto con OpenvSwitch. Come documentato nel Paragrafo 3.6.2, sono stati trovati altri colli di bottiglia che, una volta rimossi, hanno permesso di ottenere un ulteriore miglioramento di un fattore 3.
Le modifiche richieste alle applicazioni sono comunque poche rispetto alla dimensione totale del codice. Esse hanno permesso di risolvere delle inefficienze comunque presenti, ed indipendenti dal fatto di avere
5Con packet I/O si intende l’operazione di movimentazione dei pacchetti dalla rete al processo o al thread che li utilizza
e viceversa.
6pps: Packets Per Second
7Chiaramente, l’incremento di prestazioni dipende molto dal tipo di funzionalit `a delle applicazioni. Applicazioni che
quella pi `u veloce ha dato un ulteriore incremento di prestazioni, circa 4..8 volte migliori.
I risultati ottenuti con Click sono estremamente importanti perch ´e esso `e molto diffuso ed utilizzato. Ci si aspetta che gli stessi miglioramenti si possano ottenere anche con altre applicazioni che elaborano pacchetti di rete, come per esempio firewall e supervisori di traffico. Le implicazioni sono abbastanza importanti, e vanno dall’allungamento della vita utile degli apparati gi `a esistenti, al miglioramento delle prestazioni della prossima generazioni di apparati di rete.
Il codice sorgente che `e stato usato per questo lavoro `e pubblicamente disponibile [58] e pronto per essere usato in sistemi di produzione.