Bilanciamento di traffico VoIP su reti wireless

Transcript

1 Bilanciamento di traffico VoIP su reti wireless Sommario Scenario e Obiettivi Ipotesi Progettazione Valutazione Conclusioni Relatore: Dott. Vittorio Ghini Candidato: Diego Rodriguez

2 Scenario e Obiettivi Sviluppo di un sistema per il bilanciamento di carico basato sul protocollo UDP per VoIP su reti Wireless L architettura di riferimento:

3 Informazioni per il bilanciamento Kernel modificato Notifica di consegna del frame inviato all Access Point

4 Introduzione alla progettazione Scelta del canale di trasmissione Notifica Kernel Monitoraggio dei pacchetti ricevuti dall altro end-system Criterio di ritrasmissione dei frame inviati

5 Progettazione Notifica Kernel, permette di verificare se la frame inviata è stata correttamente ricevuta dall Access Point Heart Beat, rappresenta il meccanismo utilizzato dal bilanciatore di carico per controllare l affidabilità dei canali di trasmissione Errori di trasmissione, tramite le informazioni ricavate è possibile verificare se ci sono stati errori durante la trasmissione per gestirli poi in maniera opportuna Chiave di riconoscimento, la possibilità di spostamento del lato mobile può causare il cambiamento del suo IP, per questo motivo si è utilizzata una chiave per identificare le frame scambiate dai due dispositivi Miglior socket, la raccolta delle informazioni viene poi utilizzata per stabilire quale dei canali di trasmissione presenti è il più performante in termini di velocità e perdita di pacchetti

6 Lato Mobile Il comportamento del bilanciatore mobile è il seguente: Determinare l interfaccia migliore per la spedizione, inviare i dati e controllare eventuali errori di trasmissione per effettuare il rinvio Tutti i pacchetti ricevuti sono direttamente inviati all applicazione locale (anche in questo caso vengono gestiti i possibili errori) Per ogni pacchetto ricevuto si effettua il calcolo della latenza grazie al timestamp presente al suo interno Ad intervalli regolari di tempo (circa 450 ms) viene inviato un pacchetto particolare (Heart Beat) che contiene al suo interno la quantità di pacchetti ricevuti fino a quel momento dal lato fisso Per ogni Heart Beat inviato, il lato mobile si aspetterà un Heart Beat di risposta che conterrà la quantità di pacchetti che il lato fisso ha ricevuto Alla ricezione di un pacchetto di Heart Beat sarà avviata una procedura di riordinamento dei canali che una volta terminata permetterà di capire quale è il socket migliore secondo latenza e perdita di pacchetti

7 Lato Fisso Il comportamento del bilanciatore fisso è il seguente: Inviare i dati e controllare eventuali errori di trasmissione per effettuare il rinvio Tutti i pacchetti ricevuti sono direttamente inviati all applicazione locale (anche in questo caso vengono gestiti i possibili errori) Per ogni pacchetto ricevuto si effettua il calcolo della latenza grazie al timestamp presente al suo interno Per ogni Heart Beat ricevuto, se ne invierà uno di risposta contenente la quantità di pacchetti ricevuta fino a quel momento dal lato mobile Alla ricezione di un pacchetto di Heart Beat sarà avviata una procedura di riordinamento dei canali che una volta terminata permetterà di capire quale è il socket migliore secondo latenza e perdita di pacchetti La differenza principale è che il lato fisso si lascerà guidare dal mobile per determinare a quale indirizzo IP inviare i dati dell applicazione locale utilizzando i dati raccolti soltanto nel caso in cui non vengano ricevuti pacchetti di Heart Beat

8 Algoritmo ordinamento canali Entrambi i bilanciatori di carico utilizzano la stessa funzione per stabilire se un canale di comunicazione è migliore di un altro Le seguenti condizioni indicano le regole secondo le quali un canale dovrebbe precedere un altro nell ordinamento: Stessa percentuale e delay minore Percentuale maggiore e delay minore di SORT_DELAY_MAX Percentuale minore, delay del secondo socket maggiore di SORT_DELAY_MAX e delay del primo socket minore del delay del secondo socket

9 Prove e risultati Configurazione Simulatore Access Point Drop Delay Lost AP 0 2,00% 80 ±10 2,00% AP 1 2,00% 50 ±10 10,00% Lato Fisso Statistiche AP 0 Lato Drop Lost Recv Mobile Fisso Statistiche AP 1 Lato Drop Lost Recv Mobile Fisso Lato Mobile Statistiche Applicazioni App Ricevuti Inviati Mobile Fissa

10 Conclusioni e Sviluppi futuri E stato sviluppato un bilanciatore di carico per applicazioni VoIP I risultati ottenuti sono soddisfacenti Può essere migliorato per quanto riguarda sicurezza e performance E possibile estendere la sua struttura per supportare nuovi scenari Cambio Architettura (mobile-to-mobile)