Analisi dell avvio del TCP su canali satellitari a larga banda. Candidato Giovanni Verrecchia

Transcript

1 Analisi dell avvio del TCP su canali satellitari a larga banda Candidato Giovanni Verrecchia Relatore Francesco Potortì Controrelatore Maurizio Bonuccelli

2 Il progetto SatNEx Acronimo di European Satellite Communications Network of Excellence E nato nel 2004 Conta 22 partner Obiettivi: raggiungere un integrazione della ricerca europea nell ambito delle comunicazioni satellitari; sviluppare una base di conoscenza comune.

3 Problematiche affrontate Studio dell avvio di una connessione TCP su un canale satellitare geostazionario a larga banda Il comportamento del TCP, nella fase di avvio, è talvolta disastroso e la velocità di trasmissione può essere ridotta ad un pacchetto per RTT Tale comportamento è analizzato sia mediante simulazione sia mediante prove dirette su di un canale satellitare reale

4 Il protocollo TCP Transmission Control Protocol E definito formalmente in RFC 793, RFC 1122 e RFC 1323 E un protocollo del livello trasporto Fornisce un flusso di byte affidabile tra sorgente e destinazione Offre un servizio connection-oriented

5 Il controllo della congestione Due algoritmi: Slow Start e Congestion Avoidance cwnd (segmenti) Slow start threshold Si verifica un timeout Slow start threshold ridotta a 20 Slow start threshold tempo

6 Varianti del protocollo TCP Le prime versioni del TCP commercializzate da BSD si sono dimostrate affidabili, ma incapaci di fornire prestazioni accettabili se utilizzate in reti di grandi dimensioni Sono state introdotte diverse varianti del protocollo: Reno NewReno Sack Westwood

7 TCP NewReno La procedura di Fast Recovery si differenzia da quella presente nel Reno Rilevata la perdita di un segmento, lo ritrasmette. L Ack ricevuto di conseguenza può essere parziale o completo Ritrasmissione del successivo segmento perso se l Ack è parziale, uscita dal Fast Recovery se l Ack è completo In RFC 3782 sono descritti due differenti comportamenti in risposta ad un Ack parziale: variante Slow but Steady: riarmo del timer di ritrasmissione per ogni Ack parziale; variante Impatient: riarmo del timer di ritrasmissione solo per il primo Ack parziale.

8 TCP Sack Sack = Selective Acknowledgment Il ricevitore può indicare con esattezza al trasmettitore quali segmenti sono arrivati a destinazione, in modo tale da evitare inutili ritrasmissioni

9 Il simulatore ns-2 E un simulatore di reti ad eventi discreti Supporta simulazioni dei protocolli TCP e UDP Il backend è in C++, il frontend è in OTcl Un generico scenario di simulazione è descritto mediante uno script OTcl nel quale sono definiti: lo scheduler degli eventi; la topologia della rete; il traffico; gli eventuali moduli di errore; la traccia di simulazione.

10 Un semplice script OTcl #Crea un oggetto Simulator set ns [new Simulator] #Apre il file di traccia NAM set nf [open out.nam w] $ns namtrace-all $nf Traccia della simulazione #Imposta una connessione TCP set tcp [new Agent/TCP] $ns attach-agent $n0 $tcp set sink [new Agent/TCPSink] $ns attach-agent $n2 $sink $ns connect $tcp $sink #Definisce una procedura 'finish' proc finish {} { global ns nf $ns flush-trace #Chiude il file di traccia NAM close $nf #Esegue Nam con il file di traccia exec nam out.nam & exit 0 } #Crea tre nodi set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] #Crea i link tra i nodi $ns duplex-link $n0 $n1 2Mb 10ms DropTail $ns duplex-link $n1 $n2 1Mb 20ms DropTail #Imposta la dimensione della coda #del link (n1-n2) a 10 $ns queue-limit $n1 $n2 10 Topologia della rete #Imposta un FTP su una connessione TCP set ftp [new Application/FTP] $ftp attach-agent $tcp #Specifica il link affetto da perdite #e quali pacchetti perdere set LossyLink [$ns link $n1 $n2] set em [new ErrorModel/List] $em droplist { } $LossyLink errormodule $em #Schedula gli eventi per l agente FTP $ns at 1.0 "$ftp start" $ns at 4.0 "$ftp stop" #Invoca la procedura finish dopo 5 secondi #di simulazione $ns at 5.0 "finish" #Fa partire la simulazione $ns run Scheduler degli eventi Traffico Modulo di errore

11 Modifiche al codice del simulatore Analisi e studio del comportamento del simulatore ns-2 ed in particolare: dell aggiornamento di cwnd dopo un RTO: secondo RFC 3782, cwnd resta invariata; secondo ns-2, cwnd è incrementata; della risposta agli Ack parziali: variante Slow but Steady; variante Impatient

12 Aggiornamento di cwnd dopo un RTO Per ogni Ack duplicato successivo al terzo: in RFC 3782, cwnd rimane invariata; nel simulatore, cwnd è aumentata di un segmento. Entrambi i comportamenti sono corretti: il primo si rivela meno aggressivo dell altro se si tiene conto del numero di segmenti inviati.

13 Aggiornamento di cwnd dopo un RTO Simulazioni Comportamento conforme a RFC 3782 Comportamento del simulatore ns Segmenti Segmenti Segmenti Perdite Ack Segmenti Perdite Ack Tempo (s) 0 0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 Tempo (s)

14 Risposta agli Ack parziali La variante Impatient comporta un recupero veloce e prestazioni migliori quando si perdono molti segmenti La variante Slow but Steady offre prestazioni più alte quando un numero ridotto di segmenti è perso e il RTO è sufficientemente piccolo da far scattare il timer di ritrasmissione Le classi di ns-2 che simulano un two-way TCP implementano soltanto la variante Slow but Steady

15 Risposta agli Ack parziali Simulazioni Slow but Steady Impatient Segmenti Segmenti Segmenti Perdite Ack Segmenti Perdite Ack 0 0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5 5,5 6 Tempo (s) 0 0 0,5 1 1,5 2 2,5 3 3,5 4 Tempo (s)

16 Esperimenti in ns-2 Studio del comportamento del TCP su canali satellitari geostazionari a larga banda e in dettaglio: della perdita del primo burst di dati; delle reazioni delle varianti Reno, NewReno e Sack. a1 100 Mbit/s 1ms n3 1 8 Mbit/s 250ms Dati Ack n4

17 Comportamento della variante Slow but Steady del NewReno bw = 2 Mbit/s bw = 8 Mbit/s

18 Confronto tra le varianti del TCP Scenario con bw=2 Mbit/s, delay=250 ms, beta= Reno NewReno - Slow but Steady NewReno - Impatient Sack Segmenti (id) Tempo (s)

19 Controllo della congestione negli stack TCP di FreeBSD e Linux L unica variante del NewReno implementata in FreeBSD è Slow but Steady L implementazione del controllo della congestione in Linux non segue fedelmente le linee guida indicate dagli RFC La ricezione di tre Ack duplicati non è l unica indicazione di perdita di segmenti Una macchina a stati indica le azioni da effettuare in risposta agli Ack ricevuti

20 Esperimenti sul satellite Pisa Skyplex Napoli Il tempo medio di risposta è di circa 840 ms La larghezza di banda effettiva è di circa 1600kbit/s La dimensione del buffer associato al bottleneck link è di circa 1500 Kbyte

21 Misure su satellite: Linux NewReno numeri di sequenza Segmenti Ack tempo (s)

22 Misure su satellite: Linux Sack numeri di sequenza Segmenti Ack tempo (s)

23 Conclusioni: analisi simulativa Il comportamento anomalo del TCP durante la fase di avvio è causato dalla variante Slow but Steady del NewReno. La variante Impatient si rivela molto efficace in tutti gli scenari in cui si verifica la perdita di un numero elevato di segmenti. Sia la variante Impatient che l algoritmo Sack, in generale, ottengono prestazioni più alte rispetto a quelle ottenute con la variante Slow but Steady.

24 Conclusioni: esperimenti sul satellite Risultati dei primi 300 secondi di trasmissione Banda disponibile = 1600 kbit/s Buffer associato al bottleneck link = 1500 Kbyte RTT = 840 ms Throughput a regime Segmenti inviati NewReno 0.7 Mbit/s ~ % +126% Sack 1.2 Mbit/s ~34000

25 Sviluppi futuri Sperimentazione del TCP con altri stack (Mac OS, FreeBSD e Windows) Simulazione di altre varianti del TCP: ad esempio Westwood e le estensioni del Sack (Fack e D-Sack) Sperimentazione di altre varianti del TCP: ad esempio Westwood e le estensioni del Sack (Fack e D-Sack)