Domanda di finanziamento di ricerca
della Facolta' di INGEGNERIA

La rete internet, nel suo tumultuoso sviluppo, apre nuove prospettive di utilizzo nel contesto delle comunicazioni multimediali "da uno a molti", ovvero l'equivalente della diffusione radio televisiva che ha accompagnato le sorti della societa' che si e' evoluta nel ventesimo secolo.

Il conseguimento di tale (per ora ambizioso) obiettivo non e' pero' immune dallo scontrarsi con diversi ostacoli che ne impediscono una sua immediata attuazione. Il piu' evidente e' rappresentato dalla scarsa scalabilita' delle applicazioni basate sul paradigna client-server. Infatti, oltre un certo numero di clienti, il server inevitabilmente inizia a degradare le proprie prestazioni. La soluzione piu' comunemente adottata in tal caso e' quella di aumentare il numero di server a disposizione, attuando tecniche di bilanciamento del carico. Ma se il numero di clienti contemporanei continua ad aumentare, e nel caso della rete Internet ad estensione planetaria, potrebbe tranquillamente superare decine e centinaia di milioni, allora subentra un secondo fattore limitante, quello della banda in uscita dalla batteria di server, che deve permettere il transito delle informazioni dirette verso tutti i client.

In linea di principio, una soluzione perfetta al problema della saturazione della banda esiste gia', ed e' costituita dal trasporto multicast. In tal caso, l'informazione lascia il server in una unica copia, e sono gli stessi dispositivi router che instradano i pacchetti in rete, a provvedere alla loro duplicazione, quando differenti destinatari di una stessa trasmissione sono dislocati in diversi rami della rete. Sebbene tale soluzione sia sicuramente ottima, il multicast presenta altri problemi che ne ostacolano il pieno supporto da parte degli ISP commerciali; dunque, sono allo studio soluzioni alternative.

La soluzione che va sotto il nome di Application Level Multicast tenta di emulare il comportamento dei router multicast, disseminando in rete dei dispositivi cosiddetti Relay o Splitter, che possono essere pensati come una accoppiata di client e server: mentre dal lato client si richiede la ricezione del media, dal lato server lo si invia (replicandolo) a tutti i client a valle (siano essi utenti finali od ulteriori splitters). Una tale logica di funzionamento si ispira evidentemente al funzionamento dei proxy http, in cui si pone in prossimita' degli utenti un elemento di memorizzazione dei contenuti remoti, allo scopo di non impegnare la rete per il trasferimento di oggetti che non sono stati modificati a partire dal momento della memorizzazione da parte del proxy. La differenza e' che nelle trasmissioni multimendiali non si desidera la memorizzazione locale, bensi unicamente la sua replica.

Il valore aggiunto da una Content Delivery Network (CDN) alla rete Internet, e' espresso in termini di "Scale and Reach", ossia dal risultato che si possono servire una grande quantita' di clienti, il cui numero effettivo dipende direttamente dal numero di nodi che componegono la CDN, e che questo risultato e' ottenuto trasferendo i contenuti in prossimita' degli utenti stessi. Qualora un gruppo di utenti non disponga di relay nelle proprie vicinanze, soffira' dei limiti imposti sia dalla limitazione della banda condivisa dal gruppo, che dai limiti di fan-out dei relay da cui si servono. Pertanto, la CDN deve consentire in modo semplice di aggiungere ulteriori nodi che possano prendere parte attiva alla architettura di distribuzione, permettendo agli amministratori di rete stessi, di risolvere direttamente le esigenze del proprio bacino di utenza.

L'autenticazione reciproca dei nodi coinvolti, consente di mantenere il sistema di consegna sotto il controllo di uno stesso gestore, ovvero di coordinare in modo controllato l'instradamento del media tra i relay. L'operativita' di una CDN, richiede l'attuazione di una serie di componenti del servizio, ossia l'instradamento della richiesta (il richiedente viene diretto verso il relay a lui piu' vicino), la segnalazione ed il controllo (i contenuti devo essere fatti prevenire al relay piu' prossimo al richiedente), l'advertising e l'accounting (i nodi di transito devono annunciare le proprie capacita', le sorgenti devono pubblicizzare i propri contenuti, i nodi devono riferire relativamente alla propria audience).

La ricerca si articolera' in diverse tappe, che possiamo elencare nei seguenti punti:

1) Rassegna dei lavori svolti sull'argomento nell'ambito di organismi di standardizzazione internazionale
2) Definizione di un modello di riferimento terminologico e funzionale
3) Analisi dei prodotti e servizi presenti sul mercato e proposti dall'accademia, attinenti al problema in analisi
4) Definizione di una o piu' soluzioni alternative al problema, mettendo in evidenza vantaggi e svantaggi di ognuna di esse
5) Progetto di una architettura di rete idonea alla soluzione del problema, individuazione dei ruoli funzionali necessari alla sua realizzazione
6) Sviluppo dei componenti software necessari a realizzare l'architettura, riutilizzando il piu' possibile il codice open source gia' presente in rete
7) Sperimentazione pilota della soluzione individuata
8) Effettuazione di simulazioni software per verificare la scalabilita' dell'architettura in presenza di un elevato numero di client
9) Individuazione dei fattori che possono concorrerre alla ottimizzazione delle prestazioni
10) Validazione delle strategie di ottimizzazione mediante simulazioni software
11) Revisione del software realizzato per l'effettuazione dell'esperimento pilota, integrandolo con le ottimizzazioni individuate per via simulativa
12) Rilascio pubblico del codice realizzato, ed organizzazione di un esperimento su larga scala di utilizzo dello stesso

Come si vede, il programma si presenta molto dettagliato, prevedendo tutti i passi diretti verso una effettiva realizzazione della Content Delivery Network. Procediamo ora a dettagliare i singoli punti.

Per cio' che riguarda i punti 1, 2 e 3, le attivita' ad essi relative possono considerarsi gia' particolarmente progredite, e sviluppate dal proponente nell'ambito della Task-Force TERENA denominata TF-NetCast. Tale gruppo di lavoro e' composto da membri che aderiscono a titolo spontaneo, e si e' costituito sulla base del parere strategico espresso dal comitato tecnico di Terena, organizzazioine quest'ultima che offre esclusivamente un supporto di segreteria. In questo contesto, si e' proceduto alla revisione dei lavori prodotti dal gruppo di lavoro IETF denominato CDI (Content Delivery Internetworking), che si e' costituito con lo scopo di gettare le basi per la definizione di modalita' di interlavoro tra differenti fornitori di servizio CDN. Al momento attuale, l'obiettivo del WG sembra troppo precoce, non essendosi ancora costituito un mercato, ma si e' conseguita la definizione di un modello terminologico ed architetturale che costituisce una buona base di lavoro. Dal punto di vista dell'esistente, invece, si e' provveduto a raccogliere informazioni relative ai diversi produttori di dispositivi, nonche' quelle che descrivono l'operativita' di fornitori del servizio di CDN. Questa fase dello studio ha prodotto un buon livello di conoscenza dei dispositivi su cui e' possibile contare, e tra questi si e' individato lo Streaming Server Darwin della Apple come un ottimo strumento di sperimentazione e sviluppo, in quanto liberamente disponibile con un licenza di tipo Open Source, ed inoltre perfettamente configurabile in modalita "splitter", consentendo infatti di richiamare a se (pull) i contenuti disponibili presso un diverso server RTSP, rendendoli a sua volta disponibili ai suoi clienti a valle. Dal punto di vista dei fornitori di servizio, invece, non si e' riscontrata una particolare varieta' di soluzioni proposte, confermando cosi' i motivi dello scarso successo del WG IETF CDI. Il principale attore, Akami, basa infatti la sua offerta su di un meccanismo di redirezione della richiesta attuata mediante un DNS modificato, metodo per il quale sono state avanzate in letteratura obiezioni e perplessita' a riguardo della sua effettiva efficienza.

Relativamente ai punti 4 e 5, la studio attualmente si trova al punto di analizzare i requisiti, la validita' e le controindicazioni relative ad un approccio simile a quello di Akamai, ossia che basa la redirezione della richiesta su di un DNS modificato, e di confrontare i vantaggi e gli svantaggi individuati, con quelli derivanti da una originale architettura alternativa, che affronta invece in modo congiunto i problemi dell'instradamento della richiesta, dell'individuazione del miglior nodo in prossimita' del client, e del set-up della consegna dei contenuti a tale nodo. Fin da subito, possiamo concludere che, mentre l'approccio-Akamai consente di pubblicare su di un portale di annuncio l'indirizzo attribuito in modo permanente alla risorsa, consentendo una redirezione indipendente e successiva da parte del DNS, d'altra parte lascia aperto il problema di come modificare in modo dinamico la distribuzione del media, in base alla localizzazione delle richieste che pervengono, ed allo stato di carico dei nodi che sono coinvolti. L'architettura in via definizione invece, trattando i due problemi in modo congiunto, si presta efficacemente a modificare in modo dinamico la rete di distribuzione, evitando inutili impegni di risorse in assenza di richieste. D'altra parte, proprio in virtu' del fatto che la distribuzione e' attivata a seguito delle richieste del client, la nuova architettura proposta necessita di una interazione piu' stretta tra il portale di annuncio, che riceve le richieste del client, e l'entita' di controllo della CDN, che provvede ad individuare lo splitter piu' idoneo, a configurare il relaying, ed a comunicare l'esito al portale di annuncio, che quindi lo comunica a sua volta al client.

Lo sviluppo dei componenti software necessari a realizzare l'architettura (punto 6), prevede di basarsi sull'uso di Darwin streaming server, gia' menzionato, e di scrivere del codice apposito che consenta sia l'interazione tra il portale di annuncio e l'entita' di gestione della CDN, sia l'interazione tra quest'ultima ed i nodi che compongono la CDN. In particolare, i protocolli che permettono queste interazioni, definiscono unicamente il piano di segnalazione della CDN, e dunque la stessa architettura risultera' idonea anche all'uso di entita'-relay differenti da Apple Darwin SS, rendendo l'operativita' della CDN indipendente dal particolare formato/protocollo usato dalla origine dei contenuti.

Lo sviluppo dei componenti software necessari a realizzare l'architettura, ossia il punto (6), puo' essere intrapreso seguendo le linee guida dei cosiddetti Web Services, che potrebbero essere considerati gli eredi dei CGI, e che consistono nel richiedere l'esecuzione di codice su di un diverso nodo di rete, a seguito di una richiesta HTTP. Mentre nei CGI originari il passaggio dei parametri tra chiamante e nodo attuatore avviene in modo tutto sommato primitivo, attualmente si preferisce rappresentare i metadata in transito mediante una codifica XML, che permette una adeguata tipizzazione e verifica dei parametri delle richieste, e dei contenuti delle risposte. In tale ambito, sussistono diverse proposte, dalla piu' basilare XML-RPC, alla piu' articolata SOAP. I vantaggi e svantaggi delle due tecniche, saranno valutati nel corso della ricerca.

Per il punto (7) (sperimentazione pilota) ci si avvarra' della collaborazione degli altri partners della Task Force TERENA TF-NETCAST, realizzando una piccola rete di nodi su cui e' in esecuzione il codice in grado di istituire il PULL di un contenuto streaming da un nodo "a monte" al nodo stesso; inoltre, si realizzera' un componente di controllo centralizzato, a cui far afferire la registrazione dei nodi che intendono prendere parte alla CDN, e da cui si dipartono i messaggi di controllo verso i nodi. Infine, deve essere definita la modalita' con la quale il portale di annuncio puo' interagire con l'unita' di controllo della CDN. In particolare, il portale deve comunicare all'unita' di controllo l'indirizzo IP del client che richiede una risorsa; l'unita' di controllo, in base alle informazioni raccolte durante la fase di registrazione, individua il relay piu' idoneo, eventualmente altri relay intermedi, li configura tutti, e restituisce al portale di annuncio l'indirizzo del portale selezionato. La scrittura del codice da eseguire sui diversi nodi, avverra' con tutta probabilita' in PERL oppure in PHP.

Relativamente ai punti 8), 9) e 10), questi segnano il confine tra uno studio di fattibilita' ed uno studio scientifico vero e proprio. In particolare, la simulazione software di un sistema con molti nodi, e' l'unico metodo possibile per tentare di prevedere il funzionamento della CDN quando sottoposta ad un carico reale dell'ordine dei milioni di utenti. In questa fase, che si intende sviluppare grazie all'utilizzo di strumenti OpenSouce come ad esempio OMNeT++, si prevede di sperimentare l'efficienza di diverse soluzioni di strutturazione topologica della CDN, valutando l'efficacia delle decisioni prese sulla base della conoscenza di diverse grandezze di osservazione, come ad esempio il carico della CPU e l'impegno di banda, oppure anche altre informazioni relative a COPPIE di nodi, permettendo quindi di tenere conto anche delle condizioni di carico del segmento di rete tra due nodi.

I punti 11) e 12) saranno realizzati solo al termine di tutta questa lunga fase di studio e sperimentazione preliminare, sperabilmente con il contributo di qualche cofinanziamento, e... se arriviamo fin qui sara' veramente un successone !!!

La ricerca aveva per titolo

Video telefonia su reti a pacchetto, fisse e mobili

e, nonostante la sua durata prevista fosse di due anni, si e' sviluppata su di un solo anno. La sperimentazioone a riguardo ha prodotto un lavoro di tesi di laurea, publicato su internet presso

http://genni.ing.uniroma1.it/tesi/ac/indice.html

in cui si e' sperimentata l'operativita' sia del componente gatekeeper che della MCU, previsti dalla architettura H.323. In particolare, il computer su cui si e' condotta la sperimentazione, e' stato acquisito con il residuo di un differente fondo di ricerca (CNR), mentre per il software ci si e' basati sulla realizzazione Open Source OpenH323 disponibile presso http://www.openh323.org/.

La sperimentazione ha permesso lo sviluppo di un punto di incontro e contatto tra utenti di videotelefonia, che permette agli stessi di entrare in comunicazione semplicemente scambiandosi l'identificativo "alias" con cui si sono registrati al GateKeeper, senza necessita' di investigare sul proprio indirizzo internet, ne' di rivelarlo.

L'uso della unita' MCU permette invece a piu' partecipanti di condividere uno stesso spazio virtuale di comunicazione, in quanto il video che e' inviato ad ognuno dei partecipanti, risulta suddiviso in quattro parti, entro ognuna delle quali compare l'immagine di una delle ultime quattro persone che hanno preso la parola.

Lo stesso elemento MCU permette inoltre ai partecipanti di verificare la propria capacita' di inviare/ricevere video, e di ricevere audio, in quanto si e' sviluppata una interfaccia WEB capace di controllare un ricevitore televisivo, e di inviare i segnali audio e video ricevuti verso l'MCU, che a sua volta li re-invia a chi si e' collegato per prova.

I punti rimanenti del progetto (Gateway con il centralino di ateneo, interconnessione ad altri gatekeeper mondiali per condividere uno stesso piano di numerazione) sono stato giudicati al momento troppo ambiziosi, non tanto per la difficolta' intrinseca, quanto per la totale assenza, nella struttura che ospita la ricerca, di qualsiasi figura di personale tecnico al quale poi si sarebbe dovuta affidare la gestione del sistema.

L'impegno della quasi totalita' della somma finanziata, e' invece e' servita a coprire le spese di partecipazione al congresso

TERENA Networking Conference 2003 in association with the CARNET Users' Conference: Zagreb, 19 - 22 May 2003