Introduzione. Gianni Canal, Enrico Marocco, Vinicio Vercellone. Le applicazioni peer-to-peer utilizzate per file-sharing sono oggi responsabili di

Transcript

1 Cooperazione tra Internet Service Provider ed applicazioni peer-to-peer architetture Le applicazioni peer-to-peer utilizzate per file-sharing sono oggi responsabili di Gianni Canal, Enrico Marocco, Vinicio Vercellone una notevole parte del traffico Internet e di una quota significativa dei costi per aumentare la capacità di trasporto nelle reti dei service provider. Tale traffico può anche essere causa di congestioni di rete e, in generale, influire sulle prestazioni di applicazioni web, giochi online, streaming e VoIP. Questo articolo, oltre a fornire gli elementi necessari a comprendere la natura del traffico peer-to-peer, illustra i possibili approcci che i Service Provider hanno a disposizione per controllare questo tipo di traffico, miranti in vari modi a rendere più locale lo scambio di contenuti e tentare di sviluppare nuove occasioni di business. Viene inoltre presentata un'iniziativa per standardizzare una soluzione tecnica per la collaborazione tra applicazioni e reti recentemente avviata in IETF (Internet Engineering Task Force) e promossa da Telecom Italia. 1 Introduzione Il traffico Internet sta subendo da anni una trasformazione caratterizzata dall'incremento dell'incidenza del traffico generato da applicazioni peer-to-peer (P2P), utilizzate dapprima per file-sharing e di recente anche per comunicazioni real-time e streaming di contenuti live. Tale traffico, che secondo le stime costituisce tra il 40% e l'85% del totale [1] 1, può essere causa fenomeni di congestioni di rete. 1 Stime più recenti evidenziano un impatto molto maggiore del traffico video. La differenza sostanziale tra i due tipi di traffico è dovuta al fatto che, mentre i contenuti forniti da > 4

2 P2P > Figura 1 - incidenza del traffico P2P (Fonte: cachelogic) FTP Web CacheLogic Research I Internet Protocol Breakdown servizi centralizzati come YouTube o IPTV sono generalmente replicati tramite soluzioni di cache nella rete locale, il traffico P2P rimane dominante nei link inter-dominio La caratteristica distintiva delle applicazioni P2P BitTorrent, emule, Gnutella, Skype, GoogleTalk, Sopcast e PPLive consiste nel fatto che gli utenti accedono a risorse come file o media relay disponibili in centinaia o talvolta migliaia di istanze distribuite su tutta la rete (Figura 1). Se da una parte l'altissimo livello di delocalizzazione è alla base del successo di tali applicazioni, allo stesso tempo ne costituisce il punto debole in termini di prestazioni. Infatti, dal momento che lo strato applicativo non ha generalmente accesso ad alcun tipo di informazione a riguardo della topologia della rete, quando un peer deve selezionare una specifica istanza della risorsa a cui accedere, ad esempio uno o più utenti da cui scaricare un determinato file, spesso non può fare altro che ricorrere ad una scelta casuale. A causa di tale dis-ottimizzazione, sono molto frequenti casi paradossali in cui, ad esempio, i download di file occupano risorse su link oceanici, mentre gli stessi contenuti sono disponibili a pochi chilometri di distanza. Studi recenti [2] mostrano che, introducendo negli algoritmi P2P meccanismi per allineare l'overlay costituito dalle connessioni tra i peer alla topologia delle reti sottostanti, è possibile ottenere un notevole miglioramento delle performance delle applicazioni stesse, ad esempio in termini di velocità di down-load, riducendo allo stesso tempo il consumo di risorse di rete. Il grafico in figura 2 mostra come vari la distribuzione delle connessioni tra i nodi di un overlay Gnutella nel caso in cui la selezione dei peer tenga in conto della posizione geografica. Negli ultimi anni sono stati proposti diversi meccanismi per ottimizzare i sistemi P2P in base alla topologia delle reti sottostanti. Un primo approccio consiste in algoritmi distribuiti basati su misurazioni effettuate dai peer stessi, mirate a stimare proprietà dei link fisici quali delay, jitter e packet loss rate. I risultati delle misurazioni vengono poi condivisi tra i vari peer del sistema, al fine di comporre un'approssimazione condivisa della mappa della rete che ogni client può utilizzare per effettuare la scelta dei peer a cui connettersi. Oltre ad 70 avere attratto grande interesse da parte della comunità scientifica, alcuni di questi algoritmi [3, 4] sono stati implementati nelle applicazioni più diffuse e sono tut t'ora utilizzati con discreti risultati. 20 Il limite più evidente di tale 10 approccio consiste nel fatto che le misurazioni che si 0 possono effettuare dagli endpoint della rete sono generalmente o troppo costose ad esempio stime di throughput richiedono scambi di grandi quantità di dati o poco significativi ad esempio semplici misurazioni di Round Trip Time Percentage of Internet Traffic 5

3 Figura 2 - rappresentazione geografica di un overlay Gnutella nel caso in cui la selezione dei peer avvenga in maniera casuale (a sinistra) e con il supporto di informazioni di topologia (a destra) (Fonte: technishe Universitat Berlin) (RTT) non danno indicazioni sull effettiva disponibilità di banda, cruciale nel caso del file-sharing. Un approccio alternativo, investigato negli ultimi anni sia in ambito accademico che industriale, prevede un ruolo attivo degli Internet Service Provider (ISP) nel guidare le applicazioni P2P ad effettuare la selezione dei peer a cui connettersi. Tale approccio, che parte dal presupposto che l'ottimizzazione del traffico P2P è di interesse sia per gli utenti che per i provider, prevede l'esposizione da parte degli ISP di informazioni di topologia di rete in maniera controllata, in modo da permettere alle applicazioni di effettuare scelte ottimali senza però svelare dettagli di implementazione generalmente ritenuti confidenziali. Le soluzioni più promettenti su questa linea sono state proposte nel 2008 da Deutsche Telekom [2] e, quasi contemporaneamente, da una partnership industriale fondata da Verizon, Yale University e Pando Networks (un distributore di contenuti che fa uso di tecnologie P2P), diventata discretamente famosa con il nome di Provider Portal for P2P Applications (P4P) [5]. I risultati ottenuti da simulazioni e da sperimentazioni con client BitTorrent-like mostrano miglioramenti nelle performance delle applicazioni in termini di velocità di download, che variano tra il 15% e l'85%, ed una riduzione del traffico inter-dominio compresa tra il 34% e l'80%. Nel corso del 2008 Telecom Italia si è impegnata nel coordinamento del processo di creazione di un working group nell'internet Engineering Task Force (IETF) per la standardizzazione di una tale soluzione ed ora ne è alla guida insieme ad Alcatel-Lucent e Neustar. 2 Caratteristiche del traffico P2P Una prima serie approfondita di studi sulle caratteristiche del traffico P2P e sull effi- 6

4 Figura 3 - Distribuzione degli oggetti P2P in funzione della dimensione (Fonte: University of Washington) cienza delle strategie di caching è stata condotta da University of Washington [6]. Le analisi sono state effettuate nel 2002 sulla base di tracce reali raccolte sulla rete del campus universitario un bacino di oltre utenti ed hanno preso in esame il protocollo Kazaa in un periodo di 200 giorni, per un volume totale di 20TB di traffico corrispondenti a circa 1,6M di richieste di trasferimento di file. Alcune interessanti osservazioni riguardano le caratteristiche del traffico P2P analizzato. Il tipico mix di traffico di un applicazione P2P è costituito da vari tipi di oggetti, quali audio, video, eseguibili ed immagini. La natura variegata dei contenuti trasferiti si riflette sull'andamento del workload risultante (Figura 3), che evidenzia la presenza di tre diversi segmenti corrispondenti ad altrettanti tipi di oggetti: di piccola taglia (inferiore a 10 MB), di medie dimensioni (da 10 a 100 MB) e di grandi dimensioni, tipicamente vicine ad 1 GB. Come si nota dal grafico, mentre la maggioranza delle richieste (91%) si riferisce ad oggetti inferiori a 10 MB, principalmente audio, la maggior parte dei byte trasferiti (65%) è costituita da oggetti grandi, generalmente video. Da ciò si deduce tra l'altro che, se l'obiettivo è contenere il consumo di banda, bisognerà fare leva su questi ultimi; viceversa, se lo scopo è di migliorare la user experience complessiva, si dovrà tenere conto della fonte della maggioranza delle richieste. Una semplice ma importante differenza tra gli oggetti multimedia Kazaa ed il tipico workload web è dovuta al fatto che i primi sono immutabili, mentre le pagine web non lo sono. La natura dei contenuti scambiati ha delle implicazioni che si riflettono sulle caratteristiche del traffico P2P e lo rendono differente da quello web. Infatti, a differenza di quanto avviene con le pagine web, gli utenti P2P scaricano un certo contenuto solitamente una volta sola; dalle tracce di traffico Kazaa raccolte nello studio si deduce che questo si verifica per il 94% del tempo. Un'altra indicazione emersa riguarda la durata spesso limitata della popolarità degli oggetti P2P. A differenza delle pagine web più popolari, che tendono a rimanere relativamente stabili nel tempo, gli oggetti audio/video più condivisi sono spesso rimpiazzati da nuovi contenuti nell'arco di poche settimane; ciò si verifica in misura maggiore 7

5 per i contenuti audio, che tendono a perdere la loro popolarità più rapidamente di quelli video. In questa dinamica di sostituzione i contenuti più popolari tendono ad essere costituiti da oggetti apparsi di recente, specie nel caso dei contenuti audio. Tuttavia, analizzando la distribuzione delle richieste, si può constatare come la maggior parte degli accessi si riferisca invece, complessivamente, ad oggetti più vecchi: ben 72% delle richieste per quelli di grandi dimensioni e 52% per quelli piccoli. Le caratteristiche intrinseche del traffico P2P si traducono in una diversa distribuzione statistica della popolarità dei contenuti rispetto a quella del web. Mentre quest'ultima può essere notoriamente modellata da una distribuzione di tipo Zipf 2, come ampiamente riportato in letteratura, lo studio ha Figura 4 - Distribuzione di popolarita` degli oggetti web e P2P Kazaa (Fonte: University of Washington) permesso di verificare che la distribuzione di popolarità dei contenuti P2P se ne discosta in qualche misura. L'andamento è evidenziato nel grafico di figura 4, che riporta il numero di richieste per un certo oggetto in 2 La distribuzione Zipf esprime la relazione tra la frequenza (denominata anche size ) di un evento ed il suo rank, ossia la sua posizione nella classifica di popolarità relativa all insieme degli eventi considerati. Applicazioni per file-sharing: emule Il client emule è la più popolare applicazione di file sharing basata sul protocollo edonkey; di seguito ne è descritto brevemente il funzionamento. Identificativi di client e file All avvio di emule, il client sceglie un server tra quelli presenti in una apposita lista sul quale si registra stabilendo una connessione ed ottenendo un identificativo (Client ID). Dopo l assegnazione dell'id, il client invia al server della rete edonkey la sua lista di file condivisi. Ad ogni file è assegnato un File ID, che lo identifica in base al suo contenuto. In particolare, il file viene diviso in parti di 9.28 MB, alle quali viene applicato l algoritmo di hashing MD4, ottenendo degli Hashset che combinati formeranno il File ID, utilizzato anche per verificare l integrità del file scaricato. Ricerca di un file La ricerca di un file può avvenire secondo due diverse modalità. In modalità Server, il client invia un messaggio Search Files contenente le keyword di ricerca al server principale con il quale ha stabilito la connessione, e ne riceve in risposta una lista con i risultati della ricerca. Tale lista contiene, per ciascun file: il File ID, l'indirizzo IP di uno dei client che > 8

6 funzione del suo rank. Si può notare che la prima parte della curva si discosta dall andamento della distribuzione Zipf rappresentata dalla retta di interpolazione (tale scostamento è enfatizzato dall'impiego di una scala logaritmica su entrambi gli assi), anche se la correlazione rimane sempre molto elevata. In pratica, come si vede dal grafico, la curva è appiattita nella parte corrispondente ai contenuti più popolari, indicando che questi ultimi sono richiesti complessivamente un numero di volte inferiore a quanto previsto dalla distribuzione Zipf. I precedenti risultati sono confermati anche da altri studi indipendenti che mostrano inoltre come l'andamento sia caratteristico della fruizione di contenuti video, indipendentemente dal fatto che il canale utilizzato sia il download, invece che il noleggio o il botteghino. 2.1 Efficienza delle tecniche di caching L analisi condotta da University of Washington ha prodotto anche una serie di interessanti valutazioni [6] riguardo all'efficienza delle politiche di caching. È opportuno pre- > possiede il file ed ulteriori dati tra cui il nome del file, la dimensione ed il numero di fonti. In modalità Global, attivata quando il numero delle fonti non è sufficiente, il meccanismo precedente viene arricchito da una ricerca parallela, contattando altri server della sua lista, alla ricerca di ulteriori risultati. Ricerca delle fonti Individuato il file che intende scaricare, l utente lo inserisce nella lista dei trasferimenti ed invia al server su cui è registrato un messaggio Get Sources, che ne specifica il File ID, ricevendo come risposta un messaggio Found Sources con la lista degli indirizzi dei client che condividono il file. Se il numero di fonti individuate è inferiore ad un determinato valore di soglia, il client invia anche dei messaggi Get Sources ad altri server presenti nella lista, per ottenere ulteriori indirizzi di peer. Dialogo tra peer e trasferimento dei file Ottenuti gli indirizzi, il client (A) instaura una connessione con ognuno dei peer (B) nella lista, avviando una procedura di handshake che ne consente la mutua identificazione. Al termine di questa fase, A può richiedere a B il file desiderato, tramite i messaggio di File Request e File Status Request, a cui B risponde con un File Request Answer, contenente il nome del file e un File Status, che ne specifica il File ID e quali parti del file possiede. Al successivo invio a B della richiesta di download, tramite il messaggio Slot Request, possono verificarsi due situazioni: La coda di servizio di B è vuota: A riceve un messaggio di Slot Given ed avvia il download effettivo indicando le parti del file che desidera scaricare tramite il messaggio Request Parts. La coda di servizio di B non è vuota: in tal caso B comunica ad A la sua posizione all interno della coda, tramite il messaggio Queue Ranking; in funzione del ranking, la connessione può essere chiusa e riaperta da B quando A raggiungerà la testa della coda, per iniziare il download come descritto al punto precedente. In tal caso si attiva un meccanismo di keep-alive per aggiornare A sulla sua posizione in coda. Infine, al temine della ricezione delle parti del file specificate nei messaggi Request Parts, A invia a B un messaggio di Slot Release e chiude la connessione. Il messaggio Offer Files Per comunicare al server su cui è registrato la propria lista di file condivisi il client utilizza il messaggio Offer Files, nel quale specifica anche se sono disponibili interamente e parzialmente, che viene emesso al momento della connessione e rinnovato periodicamente. Il messaggio serve inoltre ad aggiornare il server quando la lista dei file condivisi cambia, in particolare al termine di un download. 9

7 mettere che si tratta di risultati teorici, ottenuti mediante simulazione di un modello ideale di cache, che rappresentano senza dubbio un limite superiore alle prestazioni ottenibili nella pratica. Gli studi mostrano in sostanza che le performance del caching di traffico P2P, valutate in termini di hit rate 3, sono paragonabili e generalmente superiori a quelle ideali del caching di traffico web [7]. La figura 5 riporta, a titolo di esempio, l andamento delle prestazioni della cache in funzione della numerosità dei client. Il grafico mostra l hit rate riferito al traffico uscente. Si può osservare che una popolazione di 1000 client percepirebbe un hit rate del 40% circa, che salirebbe al crescere del numero di peer fino a raggiungere un valore introno all'85%, nel caso di client. Ciò dimostra che l'efficacia del caching di traffico P2P, già vantaggioso per un numero contenuto di peer, aumenta significativamente al crescere della popolazione. Lo studio di University of Washington ha indagato anche i benefici derivanti dall eventuale adozione di politiche di reinstradamento delle richieste verso peer locali, come strategia equivalente al caching. L obiettivo della politica, denominata locality-aware routing, è quindi quello di sfruttare le repliche dei contenuti già presenti in ambito locale; essa si fonda sull'osservazione che, in base alle tracce analizzate, ben l 86% dei byte scaricati da peer esterni era già presente in un altro peer all interno del campus al momento della richiesta. In pratica quindi, favorendo, quando possibile, la scelta di peer locali, si realizza una sorta di caching distribuito dei contenuti. I principali risultati dell'analisi di questa strategia, assumendo un modello ideale 4, evidenziano come le prestazioni (hit rate) varino tra il 68% ed il 37%, in funzione della dimensione degli oggetti. Gli studi mostrano anche che uno dei principali fattori che influenzano l'efficienza di queste politiche è rappresentato dal livello di disponibilità dei peer che sono in grado di servire il contenuto richiesto. Infatti, la disponibilità dell oggetto richiesto non è più garantita intrinsecamente dalla presenza delle cache. Per questo, la presenza di un sottoinsieme di peer con elevata disponibilità rappresenta una condizione necessaria e sufficiente per raggiungere una buona efficienza del sistema. 3 L'hit rate è definito come la percentuale di successi nell'accesso ai contenuti all'interno della cache. 4 Il modello presuppone una conoscenza completa della disponibilità dei peer e degli oggetti serviti, assume inoltre che i peer siano dotati di capacità di storage illimitata e che non appena hanno scaricato un oggetto lo rendano dispo- Figura 5 - Prestazioni ideali del caching di traffico P2P Kazaa (Fonte: University of Washington) 10

8 Applicazioni per file-sharing: BitTorrent BitTorrent è un protocollo di file sharing peer-to-peer che conta svariate implementazioni tra cui BitComet, μtorrent ed Azureus. Su scala mondiale il protocollo è molto diffuso, mentre in ambito Europeo, ed in particolare in Italia, il traffico BitTorrent è ancora inferiore a quello edonkey. Funzionamento del protocollo Per effettuare un download, gli utenti devono procurarsi, collegandosi solitamente ad un sito web, un file con estensione.torrent che contiene informazioni sul contenuto richiesto e l indirizzo del tracker che funge da coordinatore della distribuzione. Collegandosi al tracker indicato nel file.torrent, il client ottiene la lista dei peer che sono attualmente coinvolti nella condivisione del file. In particolare, quelli che dispongono di una intera copia del file sono denominati seeder, mentre quelli che devono ancora terminarne il download leecher. Il client si connette quindi ad un sottoinsieme di questi peer scegliendo indistintamente seeder e leecher ed ottiene i diversi pezzi in cui è suddiviso il file. Il gruppo di peer connessi fra loro per realizzare il trasferimento di un file è denominato swarm. Scelta del frammento da scaricare Dopo aver ottenuto dal tracker la lista dei peer, il client inizia a contattarli per procedere alla richiesta del file. Per facilitare il download, questo viene suddiviso in pezzi, che vengono scambiati tra i peer; la decisione di quale frammento scaricare da ogni peer segue regole precise: Rarest first: prevede di scegliere per primi i pezzi condivisi dal minor numero di peer e mira ad evitare il rischio di una loro indisponibilità; Random First Piece: eccezione alla regola precedente, viene applicata all inizio del download, quando il peer non ha ancora pezzi del file per l'upload e quelli rari potrebbero essere disponibili solo su un peer; Endgame Mode: modalità utilizzata nella fase finale del download. Per evitare di scaricare pezzi da peer molto lenti, si inviano richieste per i pezzi mancanti a tutti i peer, seguite da messaggi di cancel non appena il blocco viene scaricato. Tit-for-tat L allocazione delle risorse non viene realizzata in modo centralizzato in BitTorrent, ma ogni peer si preoccupa di massimizzare la propria velocità di download. L efficienza complessiva del trasferimento dipende infatti fortemente dalle politiche utilizzate dai client per determinare a quali peer inviare o richiedere i vari pezzi del file. Per raggiungere questo obiettivo BitTorrent adotta una strategia conosciuta come tit-for-tat al fine di approssimare un sistema Pareto-efficiente. Secondo questa politica, che mira a stabilire un principio di reciprocità, nell'effettuare l'upload dei loro pezzi del file, i client privilegiano quei peer che forniscono loro altri dati in cambio. Per gestire l'upload, in modo da realizzare la strategia tit-for-tat, viene utilizzato il cosiddetto choke algorithm. Il choking consiste infatti in un temporaneo rifiuto ad inviare dati verso un peer (ma non a riceverli); il client BitTorrent decide quali peer sbloccare basandosi su criteri piuttosto elaborati, privilegiando tipicamente i peer che gli offrono la maggiore velocità di download. La lista dei peer da sbloccare viene ricalcolata ogni 10 secondi, per permettere al trasferimento di raggiungere una situazione di regime. Per ovviare a limitazioni che insorgerebbero in particolari condizioni, viene adottato un meccanismo aggiuntivo denominato optimistic unchoking. Il client riserva cioè una porzione della sua banda di upload a peer scelti in modo casuale. L'optimistic unchoking ottiene il duplice scopo di saggiare la capacità di download di nuovi peer e di gestire la fase iniziale di bootstrap all'aggiunta di un nuovo peer nello swarm. 11

9 Vale la pena notare che l utilizzo di criteri di instradamento locality-aware ha il vantaggio di permettere di superare le implicazioni di carattere legale collegate al caching di contenuti protetti da copyright. L'interesse per queste tecniche di ottimizzazione ha quindi portato alla nascita di svariate proposte che si ispirano alla strategia di locality awareness, discusse nel seguito del documento. 3 Stato dell'arte delle tecniche di ottimizzazione Tra le tecniche per l'ottimizzazione delle prestazioni dei sistemi P2P, le prime proposte in letteratura avevano lo scopo di permettere alle applicazioni di ottenere informazioni riguardanti le infrastrutture di rete per migliorare la selezione dei peer a cui connettersi ad esempio per scaricare un determinato contenuto (BitTorrent, emule), o per avere supporto per NAT traversal (Skype). Una delle prime proposte in questo senso è il sistema Global Network Positioning (GNP) [8], che ha aperto la strada al filone di ricerca dei cosiddetti Internet Coordinate System (ICS). In tali sistemi, nati con lo scopo di determinare in maniera distribuita le coordinate geografiche degli indirizzi Internet, i nodi che vi partecipano effettuano misurazioni di RTT tra di loro e calcolano la loro posizione tramite tecniche di triangolazione. GNP, pur essendo un sistema distribuito, richiede un'infrastruttura composta da nodi ben noti, detti landmark, di cui sono conosciute le coordinate geografiche. Per ovviare a questa limitazione, ricercatori del Microsoft Research Center hanno proposto una variante di GNP, Practical Internet Coordinates (PIC) [9]. L'estensione introdotta in PIC consiste essenzialmente in un meccanismo che permette di utilizzare come landmark dei nodi qualsiasi di cui sia già stata calcolata la posizione, limitando gli eventuali errori di approssimazione. Sia GNP che PIC danno ottime approssimazioni a patto che non si verifichino violazioni della diseguaglianza triangolare, ovvero che presi tre punti, A, B, C, la distanza tra A e B non risulti maggiore della somma delle distanze tra A e C e tra C e B. Purtroppo, mentre tali violazioni non si verificano nello spazio euclideo, esse sono molto comuni nelle complesse architetture di rete che compongono Internet (cioè, presi tre nodi a caso, A, B, C, non è raro che il RTT tra i nodi A e B sia significativamente maggiore della somma dei RTT tra A e C e tra C e B). Per ottenere buone approssimazioni anche in presenza di diseguaglianze triangolari, il sistema Vivaldi [3], oltre a latitudine e longitudine, introduce una terza dimensione con lo scopo di limitare errori ed anomalie, e definisce un processo continuo di approssimazione. Vivaldi si è rivelato un metodo particolarmente accurato per stimare le latenze tra nodi, tanto da venire implementato in Azureus, uno dei client BitTorrent più diffusi. Non tutte le soluzioni proposte in letteratura mirano però a realizzare un ICS. In Meridian [10], ad esempio, ogni nodo tiene traccia di un sottoinsieme di nodi vicini, organizzandoli in anelli concentrici in base alla loro distanza. Utilizzando interrogazioni ricorsive, Meridian riesce ad ottenere elevati livelli di accuratezza e, anche se il sistema risulta meno generico di un ICS, fornisce informazioni di estremo valore alle applicazioni P2P che devono ottimizzare la scelta dei peer con cui scambiare dati. Un approccio sicuramente meno rigoroso dal punto di vista scientifico, ma altrettanto efficace, è quello adottato da Ono [4], un progetto della Northwestern University. L'idea è molto semplice: invece di realizzare un sistema complesso di misurazioni e scambio di dati, il software Ono invia delle richieste fittizie ai server di Akamai, una delle 12

10 maggiori Content Delivery Network (CDN), ed utilizza i messaggi di ridirezione che ottiene come risposta per avere una stima approssimata della propria posizione. La particolarità di Ono è dovuta in parte al fatto che l'overhead di traffico generato per ottenere le informazioni è praticamente nullo, ed in parte alla popolarità che ha raggiunto come plugin del client Azureus. 4 Ottimizzazione tramite collaborazione tra ISP e P2P Invece di stimare la topologia della rete a livello applicativo tramite misurazioni end-toend ed algoritmi distribuiti, tale informazione può essere esposta dalle entità che gestiscono la rete stessa generalmente ISP ed operatori di rete. Infatti, essi hanno completa conoscenza della topologia delle reti che amministrano e, al fine di ridurre le congestioni sui link critici, sono interessati ad aiutare le applicazioni ad ottimizzare il traffico che esse generano. È essenziale notare che, affinché sia possibile un effettiva collaborazione tra ISP ed applicazioni P2P, è necessario che lo scambio di informazioni preservi un elevato livello di privacy su entrambi i fronti. Da un lato, i service provider devono essere in grado di dare indicazioni alle applicazioni senza svelare dettagli confidenziali a riguardo dell'implementazione delle proprie reti e senza comprometterne la sicurezza; dall'altro lato, gli utenti devono potere accedere alle informazioni esposte dagli ISP senza essere costretti ad indicare quale uso abbiano intenzione di farne. 4.1 P4P: Provider Portal for P2P Applications L'architettura proposta da Yale University [5] è stata adottata dal working group P4P della Distributed Computing Industry Association (DCIA), un gruppo che vede la partecipazione di numerosi ISP, vendor di hardware e software, compagnie che utilizzano tecnologie P2P ed università, riuniti con lo scopo di definire meccanismi per accelerare la distribuzione di contenuti ed ottimizzare l'utilizzo delle risorse di rete. Nell'architettura P4P (Figura 6), giocano il ruolo principale server chiamati itracker, controllati dai service provider ed acceduti dalle applicazioni o, più in generale, da elementi dei sistemi P2P per ottimizzare la scelta dei peer a cui connettersi. Un itracker può offrire tre interfacce: info: permette agli elementi del sistema P2P di ottenere informazione opaca associata ad un determinato indirizzo IP. Tale informazione è mantenuta opaca per nascondere l'effettiva topologia di rete, Figura 6 - architettura della soluzione P4P (Fonte: Yale University) 13

11 ma può comunque essere utilizzata per calcolare la distanza tra diversi indirizzi IP; policy: permette agli elementi del sistema P2P di ottenere informazioni sulle preferenze dell'operatore per quanto riguarda l'utilizzo della propria rete. Ad esempio, l'isp può utilizzare questa interfaccia per indicare un insieme di sottoreti da preferire nella scelta dei peer, in quanto provviste di accessi ad altissima velocità; capability: permette agli elementi del sistema P2P di richiedere specifiche capability, ad esempio un determinato livello di banda garantita o l'accesso ad una cache. La soluzione P4P è stata valutata con simulazioni ed esperimenti su PlanetLab 5, ed in field trial utilizzando il software di content delivery distribuito da Pando Networks (variante di BitTorrent); i risultati di tale valutazione hanno mostrato notevoli miglioramenti, sia per quanto riguarda le performance delle applicazioni che in termini di utilizzo delle risorse di rete. ISP la lista degli indirizzi dei potenziali peer che condividono una risorsa a cui l'utente è interessato un determinato file o un relay media, ad esempio per poi riceverla ordinata in base alle policy di rete. Per esempio, l'isp può preferire i peer all'interno della propria rete, magari assegnando una priorità più alta a quelli geograficamente più vicini o con accessi a capacità maggiore. Quando l'applicazione avrà ottenuto la lista ordinata, sarà poi sua responsabilità stabilire connessioni con i peer che potrà scegliere autonomamente, ma a quel punto avrà sufficiente informazione per effettuare una selezione ottimale. Tale soluzione che, oltre alla semplicità, ha il pregio di riuscire a guidare la scelta dei peer mantenendo nascosta la topologia della rete, è stata valutata con simulazioni ed esperimenti nel testbed PlanetLab e ha mostrato una significativa riduzione del traffico P2P nei link inter-dominio ed un miglioramento delle performance anche quando solo un sottoinsieme dei peer fa effettivamente uso dell'oracolo. 4.2 L'Oracolo In maniera analoga a quanto previsto dall'architettura P4P, nella soluzione proposta dai ricercatori di Technishe Universitat Berlin e Deutsche Telekom, ogni operatore di rete mette a disposizione un server, chiamato oracolo, che ha lo scopo di aiutare le applicazioni P2P a scegliere peer ottimali. A differenza della soluzione P4P, invece di fornire informazione di topologia opaca, l'oracolo espone una funzionalità di ordinamento di peer. Il meccanismo è semplice: un'applicazione P2P invia all'oracolo gestito dal proprio 5 Testbed composto di circa 900 nodi distribuiti in tutto il mondo, utilizzato da università ed enti di ricerca ( 5 Miglioramenti: dove, come e quanto Le tecniche di ottimizzazione del traffico P2P, siano esse basate su caching, su misurazioni a livello applicativo o su esposizione di informazioni a riguardo della topologia della rete, hanno il duplice scopo di migliorare le prestazioni delle applicazioni e di razionalizzare l'utilizzo delle risorse di rete. In particolare, le soluzioni proposte negli ultimi anni sono state studiate in simulazioni e field trial utilizzando per lo più applicazioni di file-sharing al fine di valutare i miglioramenti in termini di velocità di download e riduzione del traffico inter-dominio. Tra gli studi più completi ed interessanti sono sicuramente da segnalare le già citate 14