TCP a ritrasmissione asimmetrica anticipata su WiFi

Transcript

1 TCP a ritrasmissione asimmetrica anticipata su WiFi Laureando: Mirko Pedrini Relatore: Prof. Vittorio Ghini Corso di Laurea Magistrale in Informatica Alma Mater Studiorum - Università degli studi di Bologna Anno accademico 2011/2012

2 1 Introduzione Scenario e Obiettivi Perdite su canale Wifi 2 Meccanismi per la ritrasmissione Slow Start Fast Retransmit Fast Recovery 3 Progettazione Idea di base Proposta di modifica Implementazione della modifica 4 Test Sperimentali 5 Valutazione Pro e Contro 6 Conclusioni

3 Scenario e Obiettivi Il problema studiato è posto in un sistema misto, con comunicazione a base TCP aventi un tratto finale wireless. La parte wired della comunicazione è ovviamente più affidabile di quella wireless. Inoltre, complessivamente, presenta più latenza della parte non cablata. L infrastruttura wireless, per sua natura, è più soggetta a perdite di informazioni dovute a ostacoli fisici e interferenze ambientali. L obiettivo dell elaborato, quindi, è rendere più affidabile la componente wireless della comunicazione al fine di: diminuire il numero di ritrasmissioni end-to-end del protocollo TCP; sfruttare maggiormente la bandwidth del canale trasmissivo.

4 Test svolti mostrano come una semplice comunicazione in cui l host mittente si muove in un ambiente domestico possano portare a perdite di pacchetti, senza che l interfaccia di rete smetta di funzionare a causa dell eccessiva lontananza dall access point. Perdite su canale WiFi La motivazione principale per cui si vuole effettuare la modifica al protocollo è la possibilità di perdite dovute a cause esterne durante le comunicazioni wireless.

5 Meccanismi per la ritrasmissione TCP fornisce un trasferimento affidabile di pacchetti. L affidabilità del sistema è data da meccanismi di controllo della congestione della rete utilizzando timer per ogni segmento inviato. Un evento di congestione si verifica quando, per un certo intervallo di tempo, il traffico offerto alla rete dai terminali è maggiore della possibilità di smaltirlo da parte della rete stessa. Il mittente regola la quantità di dati che immette nella rete utilizzando una variabile: La Finestra di Congestione(Cwnd). Per capire se la rete è congestionata si tiene conto degli eventi di perdita: scadenza di un timeout; ricezione di 3 ACK duplicati (fast retransmit).

6 TCP Berkeley Il TCP Berkeley fu la prima versione che tentò di evitare di congestionare la rete con un eccessivo traffico modificando il ritmo di invio dei dati quando questo raggiungeva una certa soglia (SSThresh: Slow Start Threshold). Nella fase di Slow Start, Cwnd viene impostata a un valore basso e aumenta dopo ogni ACK ricevuto: Cwnd = Cwnd + 1MSS Raggiungendo il valore di SSThresh si entra nella fase di Congestion Avoidance: ad ogni ACK ricevuto si ha che Cwnd = Cwnd + 1 Cwnd In corrispondenza di un evento di congestione si ha: SSThresh = Cwnd 2 Cwnd = 1MSS

7 TCP Berkeley

8 TCP Tahoe Il TCP Tahoe introduce l algoritmo Fast Retrasmit. La ricezione di 3 ACK duplicati viene gestito come un ulteriore evento di perdita. Il TCP Tahoe si comporta esattamente come il Berkeley durante un evento di perdita, ossia porta SSThresh = Cwnd e Cwnd = 1MSS ma in questo caso 2 anche quando vengono ricevuti dal mittente 3 ACK duplicati.

9 TCP Reno Il TCP Reno introduce l algoritmo chiamato Fast Recovery, che comporta una differente reazione del mittente a seconda che si verifichi la ricezione di 3 ACK duplicati o lo scadere del Timeout. Se vengono ricevuti 3 ACK duplicati: SSThresh = Cwnd 2 e ritrasmette il pacchetto perso. Cwnd = Cwnd 2 + 3MSS Cwnd viene aumentata di 1 MSS per ogni ulteriore ACK duplicato che viene ricevuto. All arrivo dell ACK non duplicato che riscontra tutti i dati spediti successivamente al pacchetto perso Cwnd viene di nuovo abbassata al valore di SSThresh. Se l evento perdita è invece lo scadere di un timeout, il TCP Reno lo interpreta come una probabile congestione e si comporta come il TCP Tahoe.

10 TCP Reno

11 Idea di base L access point fornisce un riscontro per ogni pacchetto ricevuto dal nodo. Questo riscontro (o mancanza di tale) può essere utilizzato per conoscere l andamento della trasmissione. TED è un meccanismo utilizzato per ottenere una comunicazione affidabile tramite questi riscontri per i pacchetti UDP inviati. Per ogni pacchetto UDP inviato TED raccoglie le informazioni degli header per un possibile rinvio e le incapsula in una struttura specifica. Quando arriva un riscontro dall access point o si raggiunge il massimo numero di ritrasmissioni: Viene selezionato la struttura corrispondente dalla lista; Vengono accorpate le informazioni dalla struttura e spedite al livello applicazione.

12 Proposta di modifica Si vuole modificare il comportamento del protocollo TCP in corrispondenza di perdite nel primo hop di comunicazione. Queste, ora gestite come semplici scadenze del timer, potrebbero essere elaborate in maniera diversa cercando di aumentare la QoS della trasmissione. Modificando il modo in cui vengono selezionati i pacchetti da controllare, sarebbe possibile gestire anche quelli TCP. La ritrasmissione del pacchetto perso verrà effettuata mediante timer molto brevi, in modo da attivarsi prima del sistema attuale. Si può procedere in due modi: creazione di un nuovo evento da gestire separatamente; aggiunta di un flag alla struttura dell header TCP. Si è deciso di procedere con il primo meccanismo, scelta che ha portato notevoli benefici nella realizzazione a causa della gestione dello stack di rete.

13 Progettazione della modifica È stato necessario trovare un meccanismo per far comunicare il livello data link con quello di trasporto. I pacchetti che arrivano a livello data link, che devono essere gestiti al fine di una possibile ritrasmissione, non sono gli stessi di quelli a livello trasporto da TCP. Introducendo un nuovo campo skbid è stato possibile estendere un riferimento nello stack durante la trasmissione. Come si gestisce la frammentazione TCP? Come si gestisce la frammentazione IP?

14 Implementazione della modifica È stata quindi aggiunta tutta la gestione per i pacchetti TCP inserendo nella struttura appropriata anche un riferimento all skbid. Nel caso sia necessaria la ritrasmissione valutando la risposta dell access point: viene aggiunto il valore skbid da rinviare a un ulteriore lista. viene invocato un evento TCP PREEMP RETRANS per la gestione del rinvio da parte della funzione tcp modified retransmit timer. Considerazioni: valore massimo in cui effettuare la gestione del rinvio impostata a TCP RTO MAX/2; rinvio di tutti i pacchetti corrispondenti agli skbid presenti della lista ogni volta che viene invocata la funzione; mancato aggiornamento del conteggio delle ritrasmissioni.

15 Test Sperimentali I test sono stati svolti in ambiente domestico effettuando una comunicazione TCP tra due macchine Ubuntu 8.04 emulate. Mentre una prima è stata collegata direttamente allo switch del router, la seconda, dotata della modifica del rinvio anticipato, ha trasmesso dati mediante il canale wireless. La latenza nelle trasmissioni, invece, è stato ricreata tramite un utilizzo combinato di iptable e un applicazione ad hoc che ritarda i pacchetti bloccati dalle prime. I primi due test sono stati effettuati per testare l effettivo funzionamento del sistema col nodo mobile fermo dietro ostacoli e in movimento. Su una media di pacchetti inviati questi, rispettivamente, mostrano 62 e 94 casi di perdita gestiti dalla ritrasmissione anticipata.

16 Test Sperimentali La tabella raccoglie i risultati dei test comparativi. Questi sono stati svolti emulando le possibili caratteristiche della trasmissione quindi usando diverse latenze su un canale più o meno trafficato. Inoltre sono stati svolti test paralleli con il nodo fermo e in movimento. I risultati hanno dimostrato un generale aumento delle prestazioni, visibile in maniera più marcata nelle prove in movimento con latenze elevate.

17 Pro e Contro Pro Modifiche limitate alla parte mittente del sistema. Trasparenza della modifica da parte dell applicazione e dall altro end system. Contro Affidabilità aumentata solo in un verso della comunicazione (non da AP verso nodo mobile).

18 Conclusioni L obiettivo dell elaborato era ottenere una ritrasmissione dei pacchetti persi nel primo hop wireless al fine di aumentare la QoS della comunicazione e l utilizzo della banda. Il sistema proposto è stato realizzato su un kernel linux e testato sperimentalmente. I risultati dei test hanno mostrato un miglioramento rispetto al sistema senza il rinvio anticipato. Tuttavia i test sono stati svolti in condizioni instabili perciò, prima di procedere, sarebbe il caso di ripeterli implementando una perdita calcolabile dei pacchetti. Futuri studi basati sul lavoro effettuato potrebbero condurre a: un implementazione del sistema su ipv6. un porting del sistema TED e del rinvio anticipato su kernel linux più recenti. una modifica simile sull access point elaborando una distribuzione di openwrt.

19 Considerazione aggiuntive Una possibile soluzione allo stesso problema può consistere l aumentare il numero di ritrasmissioni direttamente a livello data link, prima che il pacchetto venga scartato. Così facendo sarebbe possibile, teoricamente, ricondursi a risultati simili al sistema implementato nell elaborato, tuttavia è necessario valutarne i limiti: controllo delle ritrasmissioni spesso gestito dal firmware dell interfaccia e non dal kernel; non tutti i pacchetti inviati necessitano di una trasmissione affidabile.