† Department of Computer Science – University of Rome “Sapienza” – Italy TCP over wireless Alcune note Un. of Rome “La Sapienza” Chiara Petrioli †

Presentazione sul tema: "† Department of Computer Science – University of Rome “Sapienza” – Italy TCP over wireless Alcune note Un. of Rome “La Sapienza” Chiara Petrioli †"— Transcript della presentazione:

1 † Department of Computer Science – University of Rome “Sapienza” – Italy TCP over wireless Alcune note Un. of Rome “La Sapienza” Chiara Petrioli †

2 2 TCP- Window based flow control Protocollo basato su sliding window L’ampiezza della finestra è data dal valore minimo tra –receiver’s advertised window – determinata dal receiver in base allo spazio disponibile nel buffer –congestion window – determinata dal sender, in base al feedback dalla rete 23456789101113112 Sender’s window Acks receivedNot transmitted

3 3 Window based flow control 23456789101113112 Sender’s window 23456789101113112 Sender’s window Ack 5 TCP window flow control è “self- clocking” Nuovi dati vengono inviati quando quelli inviati sono stati ricevuti (ack) Mantiene “equilibrio”

4 4 Meccanismi del TCP Slow start Congestion avoidance Fast retransmit Fast recovery

5 5 Sorgente Destinazione CongestionWindow = 1 CongestionWindow = 2 CongestionWindow = 4 CongestionWindow = 8 Dati ACK CongestionWindow = CongestionWindow +1 All’arrivo di ogni ACK Slow start

6 6 Sorgente Destinazione CongestionWindow = 3 Dati CongestionWindow = 2 CongestionWindow = 1 CongestionWindow = 4 ACK ADDITIVE INCREASE Congestion avoidance Incremento lineare

7 7 Slow start + Congestion Avoidance Slow start Congestion avoidance Slow start threshold 0 2 4 6 8 10 12 14 012345678 Tempo Congestion Window size (segmenti)

8 8 Tempo Timeout Slow Start Additive Increase Congestion Window CongestionThreshold CongestionThreshold = Max( CongestionWindow/ 2,2) Congestion control - timeout Additive increase multiplicative decrease threshold = max (CW/2, 2) CW = 1 slow start fino alla threshold

9 9 Destinazione Pacchetto 1 Pacchetto 2 Pacchetto 3 Pacchetto 4 Pacchetto 5 Pacchetto 6 Sorgente ACK 1 ACK 2 ACK 6 Ritrasmissione Pacchetto 3 3 ACK Duplicati ACK Cumulativo Fast retransmit (ack duplicati) Fast retransmit non aspetta lo scadere del timeout –Attivo quando la sorgente riceve multipli (>= 3) ack duplicati (prima del timeout)

10 10 Timeout VS Fast retransmit Differente dal timeout : slow start segue timeout –timeout -> pacchetti non arrivano più a destinazione –fast retransmit -> un pacchetto viene perso, ma i successivi arrivano a destinazione –Non c’è necessità di eseguire slow start, perchè si è persa una piccola quantità di pacchetti Fast retransmit in genere è seguita dalla fase di Fast recovery

11 11 Fast Recovery ssthresh = cwnd/2 cwnd = ssthresh + number of dupacks Ritrasmette il pacchetto perso (fast retransmit) e attende l’ack Quando riceve un nuovo ack (non di un pacchetto ritrasmesso) : –cwnd = ssthreh –esegue congestion avoidance Congestion window dimezzata

12 12 Congestion Window tempo Fast recovery Stato di Congestione Leggera: la rete è congestionata, ma alcuni pacchetti arrivano a destinazione. Con 3 DUPACK viene rilevata la perdita del pacchetto, si effettua il Fast Retransmit e si entra nella fase di Fast Recovery.

13 13 Livello di trasporto in ambito wireless La soluzione naturale sarebbe usare TCP Tuttavia sorgono dei problemi –TCP assume che quando si verifica un time-out o si perdono pacchetti è per via di congestione nei router della rete Assume link affidabili (tipici dei link fissi) In ambito wireless perdita di pacchetti o time-out possono anche essere dovuti a » errori nella ricezione dei pacchetti (e.g. per fenomeni di fading) » collisioni » mobilità dei nodi che porta a temporanee disconnessioni In questo diverso scenario è opportuno diminuire fortemente il trasmission rate quando avviene una perdita? Banda trasmissiva risorse preziosa, vorremmo usarla il piu’ possibile senza congestionare la rete  non opportuno se loss sporadici Eterogeneità dei link wireless può portare a soluzioni diverse Satellite, reti cellulare o basate su AP (access Point), Reti Ad Hoc

14 14 Vari approcci Problemi legati alla comunicazione sul canale radio possono essere risolti a livello link layer Es. FEC, ARQ Problema: mancanza di sinergia tra livello di trasporto e link-layer – es. introduzione di ritardi per risolvere a livello link layer collissioni e perdita di pacchetti potrebbe far scattare time-out Approcci che ‘separano’ la parte della connessione fino al punto di accesso alla rete fissa e la parte di connessione dall’AP all’utente fisso Non si mantiene end-to-end il protocollo Richiesto intervento da ‘nuove entità’ in rete Meccanismi proposti per distinguere tra perdita di pacchetti per congestione perdita da canale radio etc… diversi meccanismi di congestion control usati a seconda dei casi Questi approcci possono a loro volta essere completamente end-to-end oppure prevedere un livello di supporto dai router della rete Nel seguito vediamo delle soluzioni che fanno riferimento a quest’ultima categoria

15 15 Soluzione 1: ECN (explicit congestion notification) Fenomeni di congestione sono ben rappresentanti dal fatto che le code di alcuni dei router si caricano eccessivamente – Drop tail scheme (usato da TCP): quando sono arrivata a riempire il buffer di coda scarto i pacchetti  dropping fornisce info usate da TCP – Difetti dell’approccio standard: Puo’ caricare troppo comunque la rete, global synchronization Non controlla i queuing delays Unfairness (se ho un misto di pacchetti TCP e UDP l’effetto del congestion control di TCP ha effetto solo sui pacchetti TCP)

16 16 Random Early Discard (RED) Prevede che i pacchettipossano essere scartati con probabilità non nulla anche prima che la coda del nodo sia completamente riempita – Stima la average queue size – Droppa pacchetti con prob p b Riduce buffer overflow, fair (chi piu’ Produce traffico ha piu’ dropping) Da indicazione sul livello di congestione – La stessa tecnica si puo’ usare per marcare i pacchetti in uscita con una –Probabilità in modo da fornire una indicazione esplicita di congestione  ECN ECN: marca il pacchetto Con probabilità p b quando la dim della coda è tra min th e min th

17 17 ECN Quando riceve un pacchetto marcato il ricevitore setta un flag nell’acknowledgment che invia al sender, informandolo della congestione La ricezione di ACK con flag settato porta a effettuare congestion avoidance Coinvolge router e end host (e richiede modifiche) – Router se un pacchetto è ECN capable e c’è congestione viene marcato altrimenti droppato secondo le regole di RED (se un pacchetto appartiene ad un flusso ECN capable è q.sa che nella fase di set up della connessione deve essere stabilita) – End host: lo stack viene modificato Aggiunta di info nell’header TCP » ECN-Echo flag (ECE) settato dal ricevitore nell’ACK per indicare presenza di congestione » Congestion Window Reduced (CWR) flag settato dal sender per informare il ricevitore del fatto che la dimensione della finestra di congestione è stata modificata e si è risposto all’ECE » ECN Echo flag viene settato negli ACK dal ricevitore fino a quando il ricevitore non riceve un pacchetto con CWR flag settato. Fast retransmit, fast recovery

18 18 Estensione di ECN per TCP over wireless Nel caso di ricezione di duplicate ACK si distingue tra i due casi 3 DUPACK contiene indicazione di congestione – congestion avoidance 3 DUPACK senza indicazione di congestione – approccio meno conservativo »faster recovery »la dimensione della finestra può essere diminuita ma non si effettua congestion avoidance (in modo da effettuare un incremento veloce della dimensione della finestra nel caso di perdita sporadica di pacchetti)

19 19 TCP Westwood Example of an end-to-end solution We want to fully maintain the end to end paradigm No change needed in the TCP/IP stack (apart from inclusion of the new protocol) and header, no collaboration and changes needed in network Improvement of TCP Reno for both wireless and wired networks with advantages expecially in wireless networks The idea is to discriminate the cause of packet loss (e.g., congestion, wireless channel) ‘Reno’ halves the congestion window after three duplicate ACKs ‘Westwood’ tries to estimate the available bandwidth, tuning the slow start threshold and congestion window accordingly (faster recovery)

20 20 TCP Westwood: how it works If I received an ACK at time t k, ACKING a data segment d k, this is an indication the available bandwidth is at least b k =d k /(t k -t k-1 ) We use a filter to estimate an average available bandwidth =Avg bandwidth(k) If ACKs have a fixed interarrival rate this maps to Avg bandwdith (k)=.9 Avg bandwith(k-1)+.1*(b k +b k-1 /2) When t k -t k-1 increases the weight of the ‘old’ samples decreases Requires a sampling every  /2. If an ACK does not arrive within this timeframe it is assumed that b k =0  if no ACK arrives the avg bandwidth exponentially decreases

21 21 Challenges Duplicate ACK means an out of order packet has been received – this segment should count for sake of bandwidth estimation Delayed ACKs an ACK is sent back for every in sequence received segment OR if a 200ms timeout expires after reception of the last segment –How to we identify and deal with delayed ACKs?

22 22 Come si calcola il d k PROCEDURE AckedCount cumul_ack=current_ack_SQN-last_ack_SQN if (cumul_ack==0) /*duplicate ACK*/ accounted_for=accounted_for+1; cumul_ack=1; endif if (cumul_ack >1) if (accounted_for >= cumul_ack) accounted_for = accounted_for – cumul_ack; cumul_ack=0; else if (accounted_for < cumul_ack) cumul_ack=cumul_ack-accounted_for; accounted_for=0; endif last_ack_SQNO=current_ack_SEQNO; acked=cumul_ack; return (acked); Si considerano i DUPACK Conta i segmenti non ACKed ma che Sono già stati considerati per la stima della banda Segmenti arrivati sono già stati considerati per la stima della banda Stima del d k

23 23 Congestion control in Westwood if nDUPACKs received ssthreshold=(BWE*RTTmin)/seg_size; if (cwin >ssthresh) cwin=ssthresh; endif Caso duplicate ACKs Banda stimata Normalizza per riportarsi in num segmenti Si setta la dimensione della finestra ad un valore Che dipende dalla stima della banda disponibile  Ci si aspetta che in situazioni di non congestione si diminuisca di una entità minore la dimensione della finestra di congestione  Sei entra una fase di congestion avoidance

24 24 Congestion control in Westwood if course timeout expires ssthreshold=(BWE*RTTmin)/seg_size; if (ssthresh<2) ssthresh=2; endif cwin=1; endif Caso timeout Banda stimata Normalizza per riportarsi in num segmenti Si setta la dimensione della finestra ad 1 e si parte con Slow start ma si è meno conservativi/più accurati nel settare ssthresh

25 † Department of Computer Science – University of Rome “Sapienza” – Italy Approccio alla modellizzazione, alla simulazione e al test di protocolli di rete Alcune note Un. of Rome “La Sapienza” Chiara Petrioli †

26 26 Sembra l’approccio migliore per testare nuove soluzioni Realizzazione e test sul campo Vantaggi: Risultati tengono in considerazione aspetti che sono pienamente catturati solo in una implementazione reale -Problemi nella propagazione sul canale fisico -Ritardi nel processing, ritardi dovuti alla esecuzione simultanea di vari task sui dispositivi -Malfunzionamenti e necessità di euristiche e schemi robusti in presenza di tali malfunzionamenti PHY 802.11 AODV Transport PHY 802.11 AODV Transp PHY 802.11 AODV Transp

27 27 Sembra l’approccio migliore per testare nuove soluzioni Realizzazione e test sul campo PHY 802.11 AODV Transport PHY 802.11 AODV Transp PHY 802.11 AODV Transp PROBLEMI: Costi dei dispositivi Limiti delle aree di deployment Complessità della gestione di un test-bed come prendere le misure, come schedulare test,… Può essere difficile accedere a dispositivi modificando lo stack in modo da implementare le soluzioni sviluppate (es. effettuare modifiche in ambito 802.11 o dongle Bluetooth). Lavorare su prototipi con APIs estese e possibilità di modifiche fa salire molto i costi. SOLO IN FASE AVANZATA DI PROGETTAZIONE Scalabilità limitata Real-life test-bed sono complessi e costosi Da realizzare, risultati application-dependent

28 28 Simulazione di rete: consente di seguire il comportamento dei nodi della rete, i vari eventi che accadono nel tempo (e.g. trasmissione e ricezione dei pacchetti), seguendo nel dettaglio il comportamento dello stack protocollare Soluzioni alternative: modelli analitici e framework simulativi Pro: scala, relativamente facile testare in una eterogeneità di condizioni Approssima la situazione reale: MODELLI USATI PER CATTURARE Il consumo energetico La propagazione del segnale su canale radio Simulatori esistenti si concentrano soprattutto sugli aspetti legati alla comunicazione, non catturando bene aspetti legati al SO, ad altre componenti del nodo etc Modello del sistema Framework simulativo Integrazione di simulazione, traces (da esperimenti reali) o emulazione

29 29 Modelli analitici: tecniche di valutazione delle prestazioni per catturare il comportamento dinamico del sistema (vari strumenti: teoria delle code, reti di code, processi di markov, semi markov, renewal reward theory,…) Tecniche di ottimizzazione consentono anche di determinare soluzioni ottime o di derivare bound sul comportamento del sistema Soluzioni alternative: modelli analitici e framework simulativi LIMITI: Molte assunzioni e approssimazioni necessarie per poter rendere trattabili i modelli analitici Risoluzione automatica del modello

30 30 Confronto tra i tre approcci ImplementazioneSimulazioneAnalisi Tempi di esecuzione Approssimazioni/assunzioni introdotte Sia nel caso di framework simulativi che di framework analitici molto è lasciato alla creatività individuale (è un’arte ) Occorre: 1) comprendere il problema, 2)modellarlo, cercando il giusto compromesso tra complessità (del modello/fraemwork), tempo di sviluppo e di risoluzione e precisione/accuratezza Serve una comprensione approfondita del problema e delle tecnologie  Quali approssimazioni posso fare SENZA impattare significativamente sui risultati?

31 31 Esempio simulazione Non basta saper ‘programmare’ – Conoscenza di SW approfonditi (simulatori di rete-perché si utilizzano simulatori di rete condivisi dalla comunità ?) – Creazione del modello del problema – Realizzazione ed implementazione del framework simulativo – Scelta degli scenari di test – Scelta delle metriche di interesse Non solo occorre individuare e definire le metriche di interesse (e.g. latenza, energia, throughput) ma occorre – stabilire scenari particolari in cui il valore delle metriche è predicibile (per verifica) – correlare piu’ metriche » per comprendere trade-off » per raggiungere una comprensione approfondita del sistema – Raggiungere una buona confidenza statistica – Analizzare i dati per comprendere la fisica del sistema Overhead complessivo oppure analizzare le varie componenti dell’overhead? Percentuale media di pacchetti persi o correlare tale percentuale con la distanza dal sink/destinazione? Energia media consumata o anche varianza/distribuzione dell’energia residua/correlare l’energia consumata alla operazioni svolte dal nodo?

32 32 Approccio (simulazione-analisi simile) Sistema complesso Scenari di simulazione -Numero di nodi -Deployment dei nodi -Caratteristiche dei nodi (energia iniziale, energy model, tecnologia utilizzata per la comunicazione, data rate) -Modello del traffico, tipi e dimensioni dei pacchetti trasmessi -Modello del canale Dump da analizzare Giocando su scenari, metriche, correlando risultati e’ possibile raggiungere una comprensione profonda del comportamento del sistema Questo tipo di analisi porta a naturali raffinamenti delle soluzioni pensate

33 33 Transitorio e steady state Di solito studiati separatamente – Consumo energetico o latenza dei pacchetti in steady state –Esempio di transitorio: si parte in una situazione in cui a rete è scarica – Occorre ‘tagliare il transitorio’ – (non sempre il sistema va in steady state) Puo’ essere interessante anche studiare il transitorio – esempio: una rete in cui in una fase di transitorio iniziale i nodi si comportano in modo diverso scoprendo rotte, dopodichè la rete comincia ad operare in una modalità standard che procede fino alla network lifetime – quanto ci metto prima che i nodi scoprano le rotte e che il sistema superi una fase transitoria iniziale? – quali sono le latenze, le probabilità di perdita dei pacchetti? Quale il degrado delle prestazioni durante questa fase iniziale?