Analisi dell avvio del TCP su canali satellitari a larga banda Candidato Giovanni Verrecchia Relatore Francesco Potortì Controrelatore Maurizio Bonuccelli
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.
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
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
Il controllo della congestione Due algoritmi: Slow Start e Congestion Avoidance cwnd (segmenti) 40 32 20 16 Slow start threshold Si verifica un timeout Slow start threshold ridotta a 20 Slow start threshold 2 1 8 4 tempo
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
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.
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
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.
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 {31 35 36} $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
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
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.
Aggiornamento di cwnd dopo un RTO Simulazioni Comportamento conforme a RFC 3782 Comportamento del simulatore ns-2 1000 1000 900 900 800 800 700 700 600 600 Segmenti 500 400 Segmenti 500 400 300 200 Segmenti Perdite Ack 300 200 Segmenti Perdite Ack 100 100 0 0 1 2 3 4 5 Tempo (s) 0 0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 Tempo (s)
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
Risposta agli Ack parziali Simulazioni Slow but Steady Impatient 70 70 60 60 50 50 Segmenti 40 30 Segmenti 40 30 20 10 Segmenti Perdite Ack 20 10 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)
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
Comportamento della variante Slow but Steady del NewReno bw = 2 Mbit/s bw = 8 Mbit/s
Confronto tra le varianti del TCP Scenario con bw=2 Mbit/s, delay=250 ms, beta=1 14000 12000 10000 Reno NewReno - Slow but Steady NewReno - Impatient Sack Segmenti (id) 8000 6000 4000 2000 0 0 5 10 15 20 25 30 35 40 45 50 55 60 Tempo (s)
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
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
Misure su satellite: Linux NewReno 25000000 22500000 1 2 3 4 1 2 1 2 3 4 1 20000000 numeri di sequenza 17500000 15000000 12500000 10000000 7500000 5000000 Segmenti Ack 2500000 0 0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300 tempo (s)
Misure su satellite: Linux Sack 25000000 22500000 20000000 17500000 numeri di sequenza 15000000 12500000 10000000 7500000 5000000 Segmenti Ack 2500000 0 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 tempo (s)
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.
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 ~15000 +59% +126% Sack 1.2 Mbit/s ~34000
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)