RELAZIONE ANNUALE CONSUNTIVA PROGRAMMA DI RICERCA SETTORE Società dell Informazione

Transcript

1 RELAZIONE ANNUALE CONSUNTIVA PROGRAMMA DI RICERCA SETTORE Società dell Informazione Progetto SP1 Reti internet: efficienza integrazione e sicurezza U.O.: CNR-IIT Responsabile U.O.: Marco Conti Linea e Tema di appartenenza: Azione1 - Simulazione e ottimizzazione di reti Internet Finanziamenti ottenuti, obiettivi, attività I finanziamenti ottenuti, le attività e gli obiettivi dell unità operativa CNR-IIT per il primo anno di progetto sono sintetizzati nella Tabella 1. ATTIVITA (Linea e/o Tema di ricerca) A1-WP 1Simulazione di reti INTERNET A1-WP 2: Algoritmi per la ottimizzazione della QoS in INTERNET Tabella I UNITÀ OPERATIVA: Istituto di Informatica e Telematica del CNR (IIT-CNR), Pisa Unità Operative Partecipanti (Sede, Responsabile scientifico) IIT, Pisa, Marco Conti IIT, Pisa, Marco Conti OBIETTIVI Finanziamento I Anno Sviluppo di una metodologia e strumenti per la simulazione di sistemi Web con garanzie sulla QoS ,00 Progettazione di nuovi protocolli a livello network, e a livello middleware. per fornire servizi Internet con garanzie di QoS ,87 TOTALE ,870 Titolo della ricerca: Progettazione e simulazione di protocolli Internet Obiettivi previsti nel I anno di attività Nel primo anno di progetto le attività dell unità operativa CNR-IIT sono state indirizzate al raggiungimento dei due obiettivi definiti in Tabella I. Entrambi gli obiettivi sono stati raggiunti come mostrato dai risultati presentati nella sezione successiva. Risultati ottenuti Le attività dell unità operativa sono state finalizzate in due direzioni principali: 1. Sviluppo di metodologie e strumenti di simulazione per la valutazione degli algoritmi e protocolli di rete sviluppati nell ambito del WP2. In particolare, e stato progettato ed implementato un modello di simulazione per lo studio di servizi Web con garanzie sulla Qualità del Servizio (QoS) ottenuta tramite tecniche di replicazione dei servizi su scala geografica. 1/10

2 2. Studio e sviluppo di nuovi protocolli, dal livello rete fino al livello middleware, per migliorare la QoS in Internet. In particolare, le attività di ricerca sono state focalizzate su due aspetti fondamentali della QoS: la responsiveness dei servizi web e il risparmio energetico in Internet in presenza di utenti mobili. Nel seguito, per ciascuna area di ricerca, sono presentate le metodologie seguite ed i risultati raggiunti. 1. Simulazione di servizi web replicati su scala geografica Questa attività di ricerca ha avuto come obiettivo principale lo sviluppo di una metodologia e strumenti di simulazione per il confronto di strategie di content-delivery in un ambiente di servizi Web replicati. In particolare, il principale risultato per il primo anno del progetto è stato la progettazione ed implementazione del modello di simulazione per il confronto delle strategie client-side di contentdelivery oggetto di studio del WP2. Per questo motivo, al fine di facilitare la compresione delle caratteristiche del modello di simulazione, di seguito viene fornita una descrizione sintetica delle strategie client-side. Un servizio Web distribuito geograficamente, viene realizzato tramite server distribuiti nella rete Internet, che mantengono gli stessi dati e forniscono detto servizio. Nelle nostre analisi si assume che il contenuto presente in ciascuno dei server sia identico. Quando si hanno diverse repliche si tratta di definire una politica per far si che il client sfrutti in termini di miglioramento della QoS la disponibilità dei dati richiesti presenti in molteplici locazioni. La politica può essere definita o vicino al server che fornisce il servizio (si parla quindi di politica server-side) o vicino al client (ci si riferisce a politiche client-side). L obiettivo della nostra ricerca nel primo anno di progetto è stato lo studio dell efficacia delle politiche client-side sia in termini qualitativi che quantitativi. Nelle politiche client-side il client svolge un ruolo attivo nel decidere da chi e come fare il download dei documenti che esso stesso richiede. In letteratura esistono diverse tecniche di tipo client-side usate per migliorare la QoS in un ambiente in cui i servizi Web sono replicati geograficamente. Le tecniche client-side possono essere suddivise in due classi principali:a) il client fa il download dei dati da un unico server (vedi Figura 1); b) il client fa il download dei dati in parallelo da tutti i server replicati (vedi Figura 2). Quando il client adotta la strategia di fare il download dei dati da un unico server, questa strategia è detta strategia single-server, l obiettivo della politica client-side diventa quello di stabilire l algoritmo per assicurare che ciascun client contatti la replica migliore per l intera durata del download. In questo caso l algoritmo per selezionare il server migliore da contattare diventa il principale problema da risolvere, poiché dalla scelta del server dipende la qualità del download. Nella strategia dove tutti i server replicati sono usati per fare il download dei dati, denominata strategia parallela, l attenzione si concentra sul modo in cui le repliche vengono utilizzate, ovvero sulla porzione di dati richiesta ad ogni singola replica. Nel nostro confronto simulativo sono state selezionate due tecniche, ognuna come rappresentante di una delle due classi sopra menzionate. Per la strategia parallela è stata selezionata una tecnica che si compone delle seguenti fasi: i) il client contatta il DNS per risolvere lo URL, quando il client riceve la lista degli indirizzi IP dei server replicati, ii) esso invia una HEAD request a tutti i server per conoscere esattamente i dati da recuperare; iii) quando il client riceve la risposta alla HEAD (che contiene la dimensione dei dati da scaricare), i dati da richiedere vengono suddivisi in blocchi di dimensione fissata ed ogni blocco viene richiesto ad una replica iv) fino a che il download non è terminato. Quando un server risponde alla richiesta di un blocco, il client 2/10

3 richiede allo stesso server un altro blocco. Server più veloci soddisfano un numero di richieste Figura 1. Strategia single-server maggiori di blocchi. Per la strategia single-server è stata selezionata una tecnica che è equivalente alla precedente per le fasi i) e ii), tuttavia all arrivo delle risposte alla HEAD request, nella strategia single-server selezionata, il client fa il download del documento soltanto dal server che ha risposto più velocemente alla HEAD request, contando sul fatto che con la HEAD request il client stima non solo la congestione della rete, ma anche il carico sul server contattato. L obiettivo del nostro studio nell ambito del WP2 è l identificazione delle soluzioni più efficienti per migliorare la QoS percepita dall utente. A tal fine la simulazione costituisce lo strumento più idoneo in quanto permette di conforntare le varie politiche variando opportunamente i paramteri che costituiscono lo scenario di studio (caratteristiche della rete, numero di client, caratteristiche dei server, ecc.). Per raggiungere questo obiettivo, nell ambito del WP1 è stato sviluppato ed implementato il Figura 2. Strategia server paralleli modello di simulazione schematizzato in Figura 3. 3/10

4 Figura 3. Modello di simulazione Mentre i modelli attualmente utilizzati nella letteratura scientifica del settore rappresentano solo alcune delle componenti che determinano la QoS end-to-end, il nostro modello di simulazione rappresenta tutte le principali entità coinvolte nelle operazioni di accesso a servizi Web replicati da parte di singoli client (intesi come singoli utenti o service provider): i client che accedono ai servizi Web i server replicati l infrastruttura della rete Internet Nel seguito presentiamo le principali caratteristiche del modello, per maggiori dettagli rimandiamo a [1]. Client. Per modellare la quantità di dati richiesta dai client generici è stata utilizzata una distribuzione lognormale 1 ( σ = 2,16, e C = 8, 27). In tal modo si è voluto rappresentare la quantità di dati richiesti da un utente che lancia anche più richieste contemporaneamente da uno stesso browser. Gli intervalli di tempo tra richieste consecutive sono indipendenti ed esponenzialmente distribuiti. Le richieste del client hanno dimensione di 200 byte. La risposta ad una HEAD request ha una dimensione di 1000 byte. Il client prima di implementare una qualsiasi strategia di quelle analizzate ha bisogno di sapere gli indirizzi IP dei server replicati. Nelle simulazioni i ritardi per contattare il DNS e recuperare tutti gli indirizzi IP sono trascurati in quanto invariante per tutte le politiche client-side analizzate. A regime il numero medio di client che adotta la stessa strategia all interno di ogni area è 60. Server. Il server è stato modellato con una coda FIFO ed un buffer di dimensioni finite. Il server ha capacità di gestire fino a 200 richieste per secondo, mentre. Il tempo di servizio per processare richieste di dati ausiliari (cioè dati in aggiunta a quelli presenti nel documento richiesto) è di un ordine di grandezza inferiore rispetto al tempo necessario a processare la richiesta del documento. Il tempo necessario a processare la richiesta del documento risulta indipendente dalla dimensione del documento. Quest ultima assunzione è basata sull osservazione che la maggior parte delle operazione del server ha la stessa complessità qualora un file o un frammento dello stesso file venga richiesto. 1 Molina, M., Castelli, P., Foddis, G. Web Traffic Modeling Exploiting TCP Connections' Temporal Clustering through HTML- REDUCE, IEEE Network, May/June 2000, pp /10

5 Internet. Particolare enfasi nella nostra analisi è stata data alla rappresentazione di quelli che sono stati identificati come i colli di bottiglia presenti nell infrastruttura di rete Internet. 2 Detti colli di bottiglia sono così definiti: primo miglio capacità del backbone problema dei peering points problema dell ultimo miglio Primo miglio. Con il termine primo miglio si vuole identificare la banda disponibile per connettere il server fornitore del servizio Web alla rete Internet. Ognuno dei server replicati è situato in una LAN connesso alla rete Internet attraverso un router (detto access router). L access router ha un buffer finito ed una politica di scarto dei pacchetti in eccesso. La capacità di questa connessione ad Internet nelle nostre simulazioni è di 4 Mbps e rappresenta il suddetto effetto del primo miglio. Capacità del backbone. La capacità del backbone rappresenta la capacità disponibile della rete. Questa capacità varia da un Network Provider ad un altro, ed è strettamente dipendente dalla capacità dei router e dei cavi di collegamento. Mentre la capacità dei cavi in fibra ottica non è un problema, la capacità dei router, ossia la capacità hardware e software di spedire i pacchetti, è pesantemente limitata dalla tecnologia corrente. Per ciascuna area è stato introdotto nel nostro modello un area router che risulta essere il router maggiormente congestionato dell area. Con questo area router si vuole rappresentare la capacità del backbone relativa al router. Il router è modellato attraverso una coda FIFO ed un buffer di dimensioni finite. Questo router d area è attraversato da i) le richieste dei client dirette ai server replicati e dalle loro risposte, ii) tutti gli altri pacchetti generati dal restante traffico Internet. Questi ultimi pacchetti rappresentano il livello di congestione del router e sono quantitativamente superiori in numero a quelli relativi alle comunicazioni client-server replicati. Per tale motivo i pacchetti per l accesso ai servizi replicati vengono processati dai router in tempo trascurabile rispetto agli altri. Ciò per le richieste dei client si traduce in un contributo trascurabile al livello di congestione del router di area. Nelle nostre simulazioni l interfaccia di tale router è settata a 10 Mbps, cioè la massima banda disponibile tra le aree è settata a 10 Mbps. Problema dei peering points. I peering points sono i punti di interconnessione (cioè router) tra diversi Autonomous System (AS). Il traffico generato in un AS è facilmente gestito all interno dello stesso AS, tuttavia quando questo traffico attraversa un peering point, entra in competizione con il traffico di altri AS. Quando questi peering points diventato sovraccarichi, questa contesa può determinare lo scarto e conseguente perdita dei pacchetti con la conseguente ritrasmissione degli stessi. Per rappresentare il problema dei peering points, la connessione tra ciascuna coppia di router di area è stata modellata attraverso una coda FIFO ed un ritardo inter-area. I tempi di servizio della coda rappresentano la velocità della linea, mentre i ritardi inter-area modellano la latenza di comunicazione tra le diverse aree geografiche. Il loro valore è compreso nell insieme [50, 500] ms in media. Detti valori rappresentano i ritardi medi sperimentati dalle linee che attraversano da un capo all altro paesi come gli USA o connessioni satellitari. 2 wwwfp.akamai.com/resources/pdf/internet_bottlenecks.pdf 5/10

6 Problema dell ultimo miglio. Il problema dell ultimo miglio riguarda direttamente la limitata connettività dell utente finale alla rete Internet. Gli utenti, fatto salvo il caso in cui trattasi di service provider, sono generalmente connessi alla rete tramite una connessione fornitagli dal proprio Internet service provider. Questa connessione può essere un grosso collo di bottiglia nel trasferimento dei dati, tenendo conto che da studi effettuati da aziende del settore 3 risulta che la percentuale di coloro che hanno ancora una connessione lenta è ancora la maggioranza degli utenti da casa. La connessione relativa all ultimo miglio è modellata da una coda FIFO per rappresentare una linea di accesso lenta a 56 Kbps tramite modem. Quando la connessione viene ritenuta veloce la modellazione avviene attraverso una connessione a 10 Mbps. La qualità del servizio fornita quando un client accede ad un servizio Web replicato è espressa attraverso lo User Response Time (URT) ovvero il tempo che intercorre dal momento in cui viene effettuata la richiesta di un documento a quello in cui il documento risulta essere disponibile. Questo tempo tiene conto anche della fase relativa all eventuale scelta del/dei server replicati da cui fare il download del documento. Lo URT include sia i ritardi introdotti dalla rete (colli di bottiglia e latenza) che quelli relativi al processing della richiesta da parte dei server. Nello scenario presentato in Figura 3 è possibile distinguere 4 aree diverse, rappresentanti 4 Autonomous System (AS) ovvero 4 aree geografiche distinte. In ogni area è collocato un server di un servizio Web replicato e un pool di client che accedono a tale servizio adottando la stessa politica client-side. Poiché i carichi sulla rete e il numero di richieste per area varia in funzione del tempo, per rappresentare una situazione realistica ogni area è congestionata in modo diverso dalle altre e sperimenta un carico diverso in termini di richieste fatte al server. Una presentazione dettagliata dell ambiente di simulazione è fornita in [4]. La validità del nostro ambiente di simulazione è stata verificata utilizzando il modello di simulazione per un confronto preliminare delle varie politiche client-side [1]. 2. Progettazione di nuovi protocolli a livello network, e a livello middleware. 2.1 Servizi Web replicati L obiettivo principale è stato quello di definire e valutare soluzioni architetturali per la realizzazione di servizi Web con garanzie sulla QoS ottenute tramire replicazione su scala geografica. Un servizio Web distribuito geograficamente, viene realizzato tramite diversi server che sparsi nella rete Internet mantengono gli stessi dati e forniscono detto servizio. Nella maggior parte dei casi invece di avere tanti server replicati si hanno cluster distribuiti. Nelle nostre analisi si assume che il contenuto presente in ciascuno dei server sia identico. Quando si hanno diverse repliche si tratta di definire una politica per far si che il client sfrutti in termini di miglioramento della QoS la disponibilità dei dati richiesti presenti in molteplici locazioni. La politica può essere definita o vicino al server che fornisce il servizio (si parla quindi di politica server-side) o vicino al client (ci si riferisce a politiche client-side). Nel caso di politiche server-side, il client non prende alcuna decisione in merito alla scelta del server da cui fare il download delle informazioni. Questo tipo di politica è realizzata nei dispositivi commerciali. Nel caso delle politiche client-side, il client svolge un ruolo attivo nel decidere da chi e come fare il download dei documenti che esso stesso richiede /10

7 Nella prima fase dell attività di ricerca sono state confrontate due tipi di architetture, server-side e client-side, mostrando i vantaggi e svantaggi di entrambe le soluzioni [6]. Questa analisi ha permesso di evidenziare che le soluzioni server-side sono bastate su soluzione proprietarie (es. un recente prodotto commerciale, della CISCO, denominato DistributedDirector) ed estremamente costose in quanto richiedono dispositivi dedicati. Inoltre la visione della QoS offerta da questi sistemi ha una prospettiva, server-side, che non sempre rappresenta in maniera precisa la QoS percepita dagli utenti. Al contrario, le soluzioni client-side sono a basso costo (richiedono solo l istallazione a lato client di alcuni moduli software) e permettono di ottimizzare la QoS percepita dagli utenti di un servizio web. Pertanto, nella seconda fase della nostra attvità di ricerca abbiamo affrontato lo studio dell efficacia delle politiche client-side sia in termini qualitativi che quantitativi. In letteratura esistono diverse tecniche di tipo client-side usate per migliorare la QoS in un ambiente in cui i servizi Web sono replicati geograficamente. Queste tecniche possono essere raggruppate in due classi principali (vedi Figura 4): i) il client recupera informazioni da tutti i server disponibili, oppure ii) il client fa il download delle informazioni richieste da un solo server. In questo secondo caso bisogna definire un algoritmo che assicuri la scelta del miglior server per l intera durata del download. La selezione del server migliore può essere difficile da raggiungere, tuttavia la scelta condiziona la percezione della QoS resa disponibile per il client che vuole accedere al servizio. Qualora vengano scelte tutte le repliche per fare il download dei documenti, particolare attenzione viene data alla modalità con cui si prelevano i dati contemporaneamente da tutte le repliche. Nella nostra analisi è stata fatta una tassonomia per capire a che livello possono essere prese le decisioni in una politica di tipo client-side [6]. Per ottenere questa tassonomia è stata suddivisa la singola operazione di accesso al servizio Web in quattro fasi principali: i) probing iniziale, ii) scelta del/dei server, ii) modalità di download ed infine iv) monitoraggio del download. Nella fase di probing iniziale viene stimata la velocità di risposta e quindi la disponibilità del servizio replicato. La fase di scelta del server sfrutta le informazioni collezionate nella prima fase e decide da quali server fare il download dei dati. La modalità di download definisce il modo in cui vengono recuperati i dati dai server, infatti il client può recuperare dati sotto forma di frammenti o di singole entità. Nel monitoraggio del download si monitora la QoS fornita al client per cercare di mantenerla ad un livello accettabile eventualmente coinvolgendo repliche non coinvolte ed escludendone altre poco performanti. L analisi delle strategie di tipo client-side ha portato ad individuare le soluzioni più promettenti per migliorare la QoS percepita dall utente. Queste soluzioni sono state analizzate in dettaglio anche attraverso studi simulativi utilizzando il modello di simulazione sviluppato nel WP1 (si veda la Figura 3). 7/10

8 Client-side Strategies One Server Many Servers Minimum Hops Available Bandwidth Minimum Latency Variable-Size Blocks Fixed-Size Blocks Encoded Blocks Figura 4. Strategie client-side In particolare i risultati ottenuti [1][4][6] indicano che le soluzioni che utilizzano una singola replica sono da preferirsi quando: si utilizzino servizi in lettura-scrittura, si utilizzino servizi web sicuri (cioè protetti tramite crittografia), l utente utilizzi connessioni ad Internet via modem, ed in generale per il classico traffico web composto in gran parte da file di piccole dimensioni. I servizi di tipo parallelo costituiscono una soluzione efficiente dal punto di vista prestazionale quando l utente richieda il download di file di grosse dimensioni utilizzando linee di accesso veloci (es. rete locale) Politiche per il Risparmio Energetico e la Qualità del servizio in Servizi Internet Questa attività è stata svolta in cooperazione con l unità operativa Ingegneria di Pisa, per questo motivo nel seguito riassumiamo i principali risultati ottenuti, mentre per maggiori dettagli si rimanda alla relazione dell UO Ingegneria Pisa. Il consumo energetico è uno degli indici prestazionali principali per caratterizzare la QoS in Internet, in presenza di utenti mobili. In particolare, il consumo energetico della scheda di rete è un componente fondamentale del consumo energetico di un dispositivo mobile. Inoltre, come abbiamo dimostrato attraverso il nostro studio sperimentale [2] la pila di protocolli TCP/IP ha un impatto negativo sul consumo energetico. Infatti, con le tecnologie attuali l ottimizzazione del risparmio energetico si ottiene minimizzando il tempo in cui la scheda di rete rimane attiva (cioe negli stati di trasmissione, ricezione o idle), mentre al contrario il protocollo TCP tende ad aumentare il tempo di attività della scheda. Per questo motivo, nell ambito del primo anno del progetto, abbiamo progettato, implementato e validato strategie per il risparmio energetico da parte di utenti mobili che accedono ad Internet in cui l elemento chiave delle strategie è la massimizzazione (durante le sessioni di accesso ad Internet) del tempo in cui la scheda di rete rimane in uno stato di inattività. Questo processo di massimizzazione (che corrisponde al massimo risparmio energetico) è tuttavia vincolato dalla QoS (principalmente i tempi di risposta) percepita dagli utenti che risulta influenzata negativamente dallo stato di inattività della scheda di rete. L obiettivo dello studio è stato pertanto quello di massimizzare il risparmio energetico con un degrado trascurabile della QoS percepita dagli utenti. In particolare sono state 8/10

9 studiate e proposte due classi di politiche di risparmio energetico (application dependent e application independent), in funzione della loro dipendenza dalla semantica dell applicazione. Le politiche application dependent e application independent condividono molti elementi achitetturali di base. Entrambe, infatti, si basano sull utilizzo dell modello indiretto di accesso ad Internet (Indirect- TCP model 4 ) in base al quale un computer mobile che vuole accedere ad un servizio Internet (es. Web server) utilizza i servizi forniti da una terza entità (power-saving proxy) localizzata al bordo tra la rete fissa e la rete wireless (es. l Access Point). Diversamente dall approccio utilizzato tipicamente in Internet, una connessione a livello di trasporto tra il computer mobile ed un server web è scomposta in due connessioni: una dal calcolatore mobile al power-saving proxy e l altra dal proxy al server web. Un agente software collocato nel power-saving proxy garantisce il trasferimento dei pacchetti dati tra le due connessioni. Utilizzando questo modello indiretto è possibile introdurre, durante la sessione di accesso ad Internet, fasi di inattività della scheda di rete (cioè spenta, oppure in uno stato power saving come quello di sleep nella tecnologia ) pur garantendo la stessa semantica end-to-end per le applicazioni che usano il protocollo TCP. Infatti, durante le fasi di inattività della scheda di rete del computer mobile, l agente software che si trova sul proxy provvede a memorizzare i dati diretti verso il calcolatore mobile che in questo modo non vengono persi. I due tipi di politiche si differenziano per le strategie utilizzate nel decidere gli stati di attività e inattività della scheda di rete. Nel caso delle politiche application dependent lo stato della scheda di rete è deciso utilizzando le informazioni sulla semantica dell applicazione [5], mentre nel caso application independent le politiche da noi proposte cercano di stimare il comportamento delle applicazioni utilizzando un processo di apprendimento basato su esperti [3]. Nell ambito delle strategie application dependent abbiamo definito e confrontato su un testbed reale varie politiche [5]. I risultati ottenuti hanno mostrato che è possibile ottenere (in media) un risparmio energetico di circa 88% rispetto all approccio TCP/IP classico con un impatto trascurabile sulla QoS percepita dagli utenti (il tempo di trasferimento di una pagina web aumenta in media di 0.2 sec). Come atteso, le politiche application independent sono inferiori rispetto alle application dependent, tuttavia queste politiche riescono ad abbinare ad un significativo risparmio energetico (fino al 77% rispetto all approccio classico TCP/IP) un estrema flessibilità in quanto possono essere utilizzate per un ampia classe di applicazioni Internet senza richiedere modifiche software. 4 A.Bakre, B.R.Badrinath, Implementation and Performance Evaluation of Indirect TCP, IEEE Transactions on Computers, Vol.46, No.3, March /10

10 Prodotti della ricerca (oggetti, brevetti, prototipi, programmi,...): Programmi di simulazione e pubblicazioni in riviste e atti di conferenze internazionali del settore. Le pubblicazioni sono elencate di seguito Riviste indicizzate [1] M. Conti, E. Gregori, W. Lapenna, "Replicated Web Services: A Comparative Analysis of Client-Based Content Delivery Policies", LNCS pp [2] G. Anastasi, M. Conti, W. Lapenna, A Power Saving Network Architecture for Accessing the Internet from Mobile Computers: Design, Implementation and Measurements, The Computer Journal, Vol 46 N.1, January 2003, pp Atti di conferenze [3] G. Anastasi, M. Conti, E. Gregori, A. Passarella, Balancing Energy Saving and QoS in the Mobile Internet: An Application-Independent Approach, Proc. HICSS-36, January 6-9, 2003 IEEE Computer Society press. Rapporti Tecnici [4] M. Conti, E. Gregori, W. Lapenna, W. Client-side Content Delivery Policies in Replicated Web Services: Single-Server vs Parallel Access, ISTI-CNR Technical Report, Nov 2002, ftp://fly.cnuce.cnr.it/pub/wy/rws.pdf In corso di pubblicazione [5] G. Anastasi, M. Conti, E. Gregori, A. Passarella, Performance Comparison of Power Saving Strategies for Mobile Web Access Accettato per pubblicazione su Performance Evaluation Journal, (in corso di pubblicazione). [6] M. Conti, E. Gregori, W. Lapenna, Content Delivery Policies in Replicated Web Services: Client-side vs. Server-side, Accettato per pubblicazione su Cluster Computing n Journal, (in corso di pubblicazione). 10/10