UNIVERSITA’ DEGLI STUDI DI ROMA “TOR VERGATA” Facoltà di Ingegneria Laurea in Ingegneria delle Telecomunicazioni Tesi di Laurea Magistrale DEFINIZIONE, IMPLEMENTAZIONE ED ANALISI PRESTAZIONALE DI PROTOCOLLI DI TRASPORTO PER RETI CONTENT-CENTRIC Relatore: Prof. Stefano Salsano Co-Relatori: Prof. Andrea Detti Ing. Matteo Pomposini Candidato: Andrea Fratini 28 Aprile 2011

OBIETTIVO DELLA TESI Sommario Progettazione ed implementazione di un protocollo di trasporto per una rete content-centric Sommario Introduzione al content-centric networking Definizione di un nuovo protocollo di trasporto Implementazione in NS3 Analisi prestazionale

EVOLUZIONE NELL’USO DI INTERNET Le origini oggi Accesso tramite Nome a Contenuti (video, foto, file musicali…) Accesso tramite indirizzo IP a dispositivi di memoria e potenza elevata

TRAFFICO NELLA RETE INTERNET

CONTENT-CENTRIC NETWORKING MOTIVAZIONI L’utente valuta il servizio in termini di cosa può ottenere, mentre lo strato IP opera in termini di dove. La distribuzione dei contenuti può essere migliorata rendendo la rete content-aware e implementando caching dei contenuti nei nodi intermedi della rete (le uniche soluzioni esistenti, come CDN, sono content-aware solo a strato applicativo e sono proprietarie) L’utente vuole ricevere contenuti affidabili, ma allo stato attuale l’utente è costretto a fidarsi di chi fornisce il contenuto e non del contenuto stesso.

CONTENT-CENTRIC NETWORKING PRINCIPI Il Contenuto desiderato è richiesto attraverso un nome che lo caratterizza, tale nome diventa l’indirizzo dello strato di rete Qualunque nodo intermedio che possiede una replica del Contenuto nella sua cache può rispondere ad una richiesta e fornire il dato La sicurezza è spostata dal canale al Contenuto

Necessità di un nuovo protocollo di trasporto TCP TRASPORTO CONTENT-CENTRIC F U N Z I O A L T A’ Sender-Driven Receiver-Driven Comunicazione di natura End-to- End Nodi intermedi possono effettuare caching di un Contenuto e trasmetterlo direttamente. La dimensione della CongestionWindow limita il numero di Dati non riscontrati nella Rete La dimensione della finestra limita il numero di Richieste inoltrate (INTEREST) nella Rete. Il sender usa la ricezione degli ACK per incrementare la sua CongestionWindow Il receiver usa la ricezione dei Dati per incrementare la sua finestra di richieste. Dati e ACK inviati in sequenza da sender e receiver. Il receiver comunica quale parti del dato (chunks) vuole.

Necessità di un nuovo protocollo di trasporto Design Implementazione Valutazione prestazioni Packet Data Units Algoritmi di controllo di flusso e congestione

DESIGN Packet Data Units VIDEO (1 GB) Chunk=Parte di contenuto che identifica unità di caching della rete VIDEO (1 GB) CONTENUTO DATA Packet (256, 512 kB) Carrier-packets (1460 Bytes)

(Network-Identifier) DESIGN Carrier-packet INTEREST Header (Network-Identifier) (Chunk Number) (Payload Type) Network Identifier Chunk Number Segment info (from byte to byte) Payload Header (segment info) void payload Path state Un INTEREST è l’unità dati usata per formulare la richiesta di un Contenuto. NID= Nome del contenuto Chunk Number= Numero del chunk di appartenenza

(Network-Identifier) (signature, Signed info,…) DESIGN DATA Carrier-packet Header (Network-Identifier) (Chunk Number) (Payload Type) Network Identifier Chunk Number Security Data (signature, Signed info,…) Payload Header (segment info: da byte a byte) Segment Data Chunk Payload Path state Una DATA unit è la parte di un Contenuto, identificato da: NID= Nome del contenuto Chunk Number= Numero del chunk di appartenenza Security Data= Garanzia dell’autenticità e affidabilità del contenuto

Proprietà del protocollo content-centric CONTROLLO DI CONGESTIONE RECEIVER-DRIVEN La comunicazione è iniziata dal ricevitore, inviando un INTEREST contenente il nome di un contenuto di suo interesse. Dopo aver ricevuto i primi bytes del primo chunk effettuerà una successiva richiesta aumentando la INTEREST WINDOW. E’ il ricevitore a decidere quando la comunicazione finisce, terminando l’invio degli INTEREST. Se il DATO richiesto non è ricevuto entro un certo tempo, è compito del ricevitore ritrasmettere il relativo INTEREST CONTROLLO DI CONGESTIONE Come in TCP, una finestra limita il numero di pacchetti inviati nella rete, MA è gestita dal ricevitore Come in TCP, sono implementate le fasi di slow start e congestion avoidance, MA queste fasi sono regolate dai DATI ricevuti, non sono previsti ACK. RECUPERO D’ERRORE Come in TCP un errore in ricezione è dovuto alla mancata ricezione di un pacchetto, MA nel nostro caso di un DATO e non di un ACK. 2 casi: Trasporto Solo gli End-node 1)Nessun dato è più ricevuto fino allo scadere del TIMEOUT: Scatta algoritmo di controllo: INTEREST WINDOW ridotta e inizio fase di slow-start CONTENT-CENTRIC NETWORK 2)Ricezione di DATI fuori sequenza: -Il ricevitore accetta i DATI fuori sequenza. -Al terzo si attiva la fase di fast recovery, come per i 3ACK duplicati in TCP Under-CONET (L2, IP*, UDP/IP) Ogni nodo

Design DATI DA 0 A 700 IN CACHE End-user SERVER NODO INTEREST (0-100) Corriere.it DATA (0-100) INTEREST (101-200) DATA (101-200) INTEREST (201-300) DATA (201-300) DATI RICHIESTI NON IN CACHE INTEREST (301-700) DATA 301-700 INTEREST (701-1500) DATA 701-1500 DATI DA 0 A 700 IN CACHE

IMPLEMENTAZIONE NS3 (NETWORK SIMULATOR 3) Realizzazione di entità e protocolli in C++ WIRESHARK Dissector in LUA

Utilizzo efficiente della banda ANALISI PERFORMANCE Utilizzo efficiente della banda Work-conserving Fairness TCP-friendly

Benefici del caching CASO TCP Link 10 Mb/s 5 Mb/s Link 10 Mb/s

Benefici del caching CASO CONTENT-CENTRIC Link 10 Mb/s Content-centric Router Link 10 Mb/s Link 10 Mb/s Dato in cache

Conclusioni Il nuovo approccio content-centric networking per la Future Internet permette di migliorare la distribuzione e il reperimento dei contenuti fornendo indirizzamento attraverso i nomi, caching nativo e sicurezza nel contenuto. La definizione di un nuovo protocollo di trasporto per reti content-centric comporta il trasferimento del potere della comunicazione al ricevitore, mantenendo i vantaggi derivanti dagli algoritmi del TCP.

Grazie per l’attenzione… Conclusioni E’ stata effettuata l’implementazione e l’analisi prestazionale del nuovo protocollo di trasporto ottenendo i seguenti risultati: Raggiungimento di un utilizzo efficiente della banda Rispetto dei criteri di fairness Guardando ad una graduale integrazione col TCP, il protocollo è TCP-friendly. Uso in modo vantaggioso del caching nativo di una rete content-centric. Grazie per l’attenzione…