L’architettura generale del nostro sistema di emulazione `e rappresentata in Figura 2.2. Per poter configurare l’emulatore, gli utenti utilizzano una interfaccia semplificata, descritta nella Sezione 2.5.1. Con un semplice comando gli utenti possono definire tutte le caratteristiche dei link che intendono configurare. Le richieste vengono quindi passate ad un gestore delle risorse del nodo, che processa i comandi dati dall’utente e configura appositamente l’engine di emulazione. Prima di configurare l’emulatore, il gestore delle risorse del nodo, applica le specifiche di ottimizzazione, presentate nella Sezione 2.6 che permettono di migliorare le performance del nodo. Le ottimizzazioni sono anche necessarie per assicurare la robustezza dell’operazione di configurazione dell’emulatore, in modo tale da non sovraccaricare il nodo PlanetLab in modo eccessivo, e da gestire la condivisione dell’emulatore tra gli utenti.
Figura 2.2: Sulla sinistra, l’interazione tra utenti, vsys frontend e backend (Paragrafo 2.5.1). Sulla destra, il flusso dei pacchetti attraverso lo stack di rete, il classificatore dei pacchetti e le pipe (Paragrafo 1.2.2).
2.5.1
Vsys per dummynet: backend server
Nel nostro sistema, il backend vsys resta in ascolto per gestire le richieste di configurazione dell’emulatore. Ogni richiesta viene autenticata e vengono controllati i diritti di esecuzione per l’utente che ha effettuato la richiesta. Dopo l’esito positivo, la richiesta viene eseguita, e l’engine di emulazione viene opportunamente configurato, sfruttando le estensioni descritte nella Sezione 2.5.4 allo scopo di evitare interferenze tra il traffico appartenente ai diversi utenti del sistema.
2.5.2
Scelta dell’engine di emulazione
Nella scelta del sistema di emulazione da integrare in PlanetLab occorre effettuare uno studio preliminare sui vari emulatori disponibili e sulle loro caratteristiche, in modo tale da poter fare una scelta ragionata sulla migliore scelta per PlanetLab.
I nodi PlanetLab sono basati su una versione customizzata del sistema operativo Linux2. Su Linux es-
istono gi `a diversi sistemi di emulazione disponibili tra cui NISTnet [24], tc [7], e netpath [14] (a sua volta basato su Click [42]).
L’emulatore NISTnet non `e disponibile come componente standard in PlanetLab, pertanto il suo utilizzo `e stato scartato. tc `e un traffic shaper e un link scheduler, ma non risulta essere una buona scelta per i nostri scopi, in quando per poter modellare tutte le caratteristiche di cui abbiamo bisogno, ritardi di propagazione, riordino. . . richiede un pacchetto aggiuntivo, netem [39]. Inoltre tc `e gi `a utilizzato nei nodi PlanetLab per con- trollare il traffico dei nodi, e il nostro utilizzo potrebbe interferire con la configurazione esistente, richiedendo degli sforzi eccessivi per assicurare una coesistenza senza introdurre malfunzionamenti.
Netpath [14] ha la caratteristica principale di avere delle ottime prestazioni e di scalare bene all’aumentare del traffico. Il suo funzionamento si basa su degli hook appositamente progettati per i driver di rete e un suo stack nel processing dei pacchetti. Le prestazioni derivano invece dall’utilizzo di tecniche di polling e di “busy
netconfig client 80,443@10.20.0.0/16 SHARED profile myconfigs 802.11b-11
netconfig client 80,443@10.21.0.0/24 IN bw 512kbit/s delay 8ms OUT bw 10Mbit/s delay 3ms
Figura 2.3: Un esempio di configurazione che emula un client multihomed. I link emulati inter- cettano il traffico per due diverse sottoreti: la prima emula una rete 802.11b a 11 Mbit/s, la cui configurazione `e passata come argomento, mentre la seconda emula una linea DSL asimmetrica.
wait loops” che poco si prestano ad essere utilizzati su un nodo di PlanetLab, gi `a sovraccarico da tutti gli utenti ad esso connessi.
Dopo una attenta analisi di tutti gli strumenti a disposizione, la scelta dell’emulatore da integrare in PlanetLab `e stata quella di utilizzare dummynet. Questo emulatore `e stato gi `a oggetto di studio nella re- alizzazione di un emulatore esterno per PlanetLab nel quale sono state approfondite le conoscenze di tale strumento. Inoltre dummynet `e utilizzato anche sul testbed Emulab, quindi probabilmente `e uno strumento gi `a noto ai ricercatori.
dummynet come gi `a detto `e stato sviluppato per FreeBSD e al momento non `e disponibile su Linux, che risulta essere invece la piattaforma di riferimento di PlanetLab. Utilizzare dummynet significherebbe dover portare l’emulatore su Linux, il che, viste le conoscenze dell’emulatore stesso, richiederebbe uno sforzo non eccessivo e sarebbe un contributo utile a tutta la comunit `a.
2.5.3
Utilizzo in PlanetLab
Una delle principali caratteristiche di dummynet `e la sua interfaccia utente, semplice ed intuitiva. Anche nell’integrazione in PlanetLab si `e cercato di realizzare un’interfaccia altrettanto semplice e di facile utilizzo.
L’utilizzo diretto dell’interfaccia di/sbin/ipfwnon `e adatto agli utenti di PlanetLab, in quanto ha un elevato numero di opzioni disponibili. Inoltre, essendo su un sistema condiviso tra pi `u utenti occorre evitare che un utente a causa di un errore di configurazione renda la macchina inutilizzabile. Per questo motivo l’interfaccia realizzata su PlanetLab introduce delle tipologie di link predefinite, le quali poi possono essere configurate a piacimento dagli utenti senza il rischio di provocare danni all’intero sistema.
I link individuati (e che opportunamente combinato permettono comunque di rappresentare la maggior parte di topologie e configurazioni possibili) sono tre: server, client and service.
Una configurazione di tipo client emula un nodo dove le applicazioni si connettono a server esterni le cui porte/indirizzi sono conosciuti a priori. Il classificatore intercetta tutto il traffico da e per i server, o le porte specificate e lo passa alle pipe che emulano i link in upstream e downstream.
Una configurazione server ha invece come scopo quello di emulare un nodo dove l’applicazione da testare `e di tipo server, in ascolto su una o pi `u porte locali. Durante la fase di configurazione l’utente specifica
netconfig config client 22,80@xyz IN bw 6Mbit/s OUT bw 256Kbit/s ipfw pipe 10000 config bw 6Mbit/s
ipfw pipe 10001 config bw 256Kbit/s
ipfw add 1050 pipe 10000 in src-ip xyz src-port 22,80 sliver 50 ipfw add 1050 pipe 10001 out dst-ip xyz dst-port 22,80 sliver 50
Figura 2.4: Un esempio di utilizzo del comando netconfig e come esso viene tradotto in termini di regole e pipe nell’emulatore.
le porte locali da intercettare, e opzionalmente anche l’indirizzo remoto dei client che si connetteranno al nodo. Questo permette di poter differenziare il comportamento dell’emulatore in base al cliente connesso.
Infine la configurazione di tipo service pu `o essere usata quando si ha a che fare con un’applicazione di tipo distribuito, ad esempio un sistema P2P, dove il software in esecuzione sui nodi ha delle caratteristiche da server e client, e utilizza porte note a priori. In questo caso la configurazione dell’emulatore sar `a una combinazione di elementi client/server e permetter `a di intercettare il traffico e utilizzare lo stesso link di emulazione, tra nodi che utilizzano la stessa applicazione.
La configurazione dell’emulatore su un nodo si riduce quindi a dei semplici comandi, con i quali si definisce quale sar `a il traffico coinvolto nell’emulazione e come sono configurati i vari link. In Figura 2.3 sono rappresentate le configurazioni di un nodo. In ogni linea viene definita l’emulazione di un link bidi- rezionale, e indica quale traffico deve essere inviato alle pipe, per i link in downstream (dopo la keywordIN) e in upstream (dopo la keywordOUT). Un caso particolare `e dedicato alla configurazione di un mezzo condiviso, come ad esempio una rete WiFi. In questo caso il traffico in downstream e upstream utilizza lo stesso canale fisico, e l’emulazione utilizza la stessa pipe. Per rappresentare questa situazione viene utilizzata la parola chiaveSHARED.
Nell’esempio di Figura 2.3, viene emulato un client multihomed dove il traffico di tipo HTTP/HTTPS verso una sottorete a /16 viene rediretto su un link di emulazione, mentre il traffico verso una sottorete a /24 viene rediretto su un link con caratteristiche simili a quelle di una ADSL.
La sintassi di/sbin/ipfwaccetta anche liste di porte e indirizzi allo scopo di facilitare lo smistamento del traffico. La configurazione specifica dei paramenti relativi al link (bandwidth, delays, loss rates, o le nuove estensioni per i canali tempo varianti) `e descritta nel Paragrafo 1.3) e permette di configurare il link per le due direzioni di comunicazione. Questa configurazione permette l’emulazione di link di tipo asimmetrico.
Under the hood
Il programmanetconfigsi limita a passare le richieste al contesto di root, assieme all’identit `a dello sliver che ha effettuato la richiesta. Le porte e gli indirizzi specificati come argomento vengono utilizzati per stabilire se si sta configurando un nuovo link o modificando un link gi `a esistente. Ad ogni richiesta di configurazione vengono installate due regole nel classificatore, per selezionare il traffico in ingresso e uscita, e una o due pipe con le caratteristiche del link. In Figura 2.4 si pu `o vedere un esempio di un comando effettuato da PlanetLab e della relativa configurazione in root context che esso genera.
L’utente PlanetLab si limita a configurare il classificatore e le caratteristiche del link, mentre i numeri delle regole e delle pipe sono assegnati in root context, dal backend.
2.5.4
Isolamento tra gli utenti
Abbiamo gi `a discusso la struttura di PlanetLab e in particolare abbiamo gi `a visto che si tratta di un sistema dove diversi utenti condividono delle risorse. L’introduzione di un nuovo strumento in tale contesto non pu `o permettere ad un utente di monopolizzare le risorse, occorrer `a pertanto strutturare l’emulatore in modo da
Figura 2.5: La struttura del ruleset utilizzata nel classificatore e la tabella degli sliver utilizzata per effettuare un dispatch ottimizzato dei pacchetti al blocco di regole specifico di ogni utente.
non creare interferenze tra il traffico dei vari sliver. Per identificare correttamente il traffico delle varie slice, il backend aggiunge una opzione particolare, (sliver X) a tutte le regole. Lo sliver ID, X, viene estratto dall’identit `a dello sliver che ha richiesto al configurazione anetconfig. Durante l’esecuzione, il classificatore dei pacchetti controlla nel socket lo sliver associato ad ogni pacchetto (sia in ingresso che in uscita) e utilizza questa informazione per assicurarsi che le regole vengano applicate solo per il traffico relativo allo sliver che ha effettuato la configurazione, a prescindere dalle configurazioni che possono avere effettuato gli altri utenti.