UNIVERSITÀ DEGLI STUDI DI TRIESTE               FACOLTÀ DI INGEGNERIA                  Tesi di Laurea Specialistica in    ...
INDICEIndice delle figure ...................................................................................................
3.2 Impatto sessione di registrazione .......................................................................................
INDICE DELLE FIGUREFigura 2.1 Strutture di supporto alla registrazione RTT e RTO ............................................
INTRODUZIONETCP è un protocollo affidabile, che garantisce la trasmissione dei dati tra due endpointcostituenti la conness...
valuazione dell’impatto dovuto alle modifiche apportate, sulle performance del sistema èl’argomento del terzo capitolo, Be...
1. ARCHITETTURADa un punto di vista architetturale l’infrastruttura proposta è composta da due sottosistemi.Al primo spett...
valori di RTT e RTO vengono memorizzati listante temporale e il tipo di condizioneverificatasi al fine poter distinguere s...
“un puntatore di funzione” nel contesto utente, che viene chiamato dal                contesto kernel in presenza di dati ...
Con lo strumento proposto in questa tesi, la formula per l’aggiornamento dinamico di RTOviene caricata sotto forma di un m...
syscall con il nome della formula scelta fa si che da quel istante in poi la, i valori di RTOvengano calcolati con quella ...
2. IMPLEMENTAZIONEIn questo capitolo viene fatta una descrizione più dettagliata dell’infrastruttura proposta.Riallaciando...
2.1.1.1 Kernel built2inIl termine built-in rende meglio l’idea sull’argomento di questo paragrafo. Infatti riguardatutte l...
‘puntatore di funzione‘ (take_sample). Infine, con la presenza di variabili flag, il    rilascio della memoria relativa al...
delle relative risorse. Invece i campi che riguardano l’aggiornamento dinamico    forniscono delle informazioni utili conc...
individuata oppure non fosse disponibile in quanto già utilizzata in un’altra                   sessione il parametro rito...
in /etc/rc.d/rc.modules.Interfaccia con il contesto kernelIl modulo implementa la funzione take_sample (distinta da quella...
Nel caso la connessione TCP, oggetto della sessione di registrazione, venisse chiusa,       questo evento è segnalato al c...
tale struttura è il ‘puntatore di funzione’ che verrà chiamato in presenza di dati daelaborare. Infatti, il thread creato ...
Figura 2.3 Sessione di registrazione RTT e RTO. Buffer i – 2: già elaborato; i – 1: pieno, da elaborare; i + 2: ancora dar...
2.2 Formula RTOLa formula per l’aggiornamento dinamico di RTO è implementata nella forma di unmodulo kernel. La sua implem...
Figura 2.4 Associazione tra strutture di supporto all’aggiornamento dinamico di RTO e quella sock    Alla creazione di una...
mentre in uso. Poi vengono inizializzate una serie di costanti relativa alla formula    RTO. Infine la struttura nuova rap...
2.2.1.2 Modulo kernelI moduli kernel che aggiornano RTO devono implementare delle api con signature bendefinite. Per inizi...
•   connessione incoming ovvero in ingresso (accept)       stato TCP_SYN_RECV, intesa come ‘inviato ACK ad un pacchetto SY...
root# insmod nome_formula.ko   •      rimozione - unloading          root# rmmod nome_formulaUna volta caricati nel sistem...
•   interfaccia per l’esportazione dei dati dal contesto kernel a quello utente    •   accesso concorrenziale ai dati tra ...
La soluzione meglio adatta all’infrastruttura proposta è la seguente:    •   utilizzo di un device a caratteri        che ...
corso d’azione dello stack TCP. Tali ritardi non solo graverebbero sulla performance delsistema stesso, sull’andamento del...
Proteggere l’accesso con un lock ha degli svantaggi. Lasciando stare per un attimo ilritardo introdotto al processo in att...
Con stack = 0 viene indicata una connessione TCP ancora attiva, che alla chiusura diventastack = 1. Lo stesso ragionamento...
nella segnalazione da parte dello stack TCP di questo evento ponendo la variabile stack delrelativo elemento nella lista s...
3. BENCHMARKLe modifiche apportate nel kernel implicano indubbiamente un impatto sulla performancedel sistema. Alla strutt...
solamente quando una sessione di registrazione è in atto. Ambedue le operazioni hanno unnumero ben definito di istruzioni,...
utility del SO (systat, sysprof) si può applicare un profiling. Proprio per questo motivo lo èancora di più fare un confro...
Come si può intuire dalla figura, l’unica variabile è il kernel. Il mezzo fisico dicomunicazione tra i client ed il server...
La tabella seguente riassume la media e la durata complessiva di upload per i due kernel inconfronto.                     ...
Ambiente di testL’esperimento è simile a quello precedentemente descritto nel paragrafo 3.1. A differenzadi prima, in ques...
Figura 3.4 Confronto in base alla “durata di upload”La tabella seguente riassume la media e la durata complessiva di uploa...
4. CASI DI STUDIOPer rendere meglio l’idea di cosa offre e di come si può utilizzare l’infrastruttura propostasono stati p...
Per tutti gli esperimenti seguenti il numero dei ‘file upload/download’ è 60. La dimensionedel file varia, pertanto sarà s...
La formula standard per l’aggiornamento dinamico di RTO è riportata in (rfc2988) edomessa da questo documento per brevità....
4.1.1 Connessioni outgoingPer le connessioni outgoing vengono effettuati una serie di file upload verso un serverTCP - por...
Figura 4.2 Confronto in base alla “durata di upload”Segue il confronto tra i campioni ottenuti con la formula standard e q...
media syn inviati                    1                        1         connessioni non riuscite             0            ...
La formula per l’aggiornamento dinamico di RTO oggetto di studio comporta dei rinvii dipacchetti SYN, mentre molto probabi...
durata media upload (sec)          0.55                  0.67         somma totale durata upload (sec)   33.4             ...
Figura 4.7 Confronto in base alla “durata di upload” e “syn inviati”Si nota anche in questo caso un rinvio di pacchetti SY...
Figura 4.8 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa”La tabella seguente riassume la med...
•   la media di ‘durata di upload’ per la formula oggetto di studio è minore di quella        standard    •   la ‘durata t...
Figura 4.9 Confronto in base alla “durata di download” e “synack inviati”In questo scenario i grafici della ‘durata di dow...
Figura 4.10 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa”La tabella seguente riassume la me...
4.1.3 Riassunto ed osservazioniLa tabella seguente riporta il riassunto dei risultati, per ogni esperimento effettuato.Fig...
•    nell’eventualità di una perdita di pacchetti il loro rinvio è più veloce        nel caso i pacchetti vadano persi un ...
Essa è funzione degli ultimi 3 valori di RTT e dell’ultimo valore di RTO. La componenteRTO è utile particolarmente nel cas...
evidenziare sia situazioni ‘normali’ che casi limite.4.2.1 Connessioni outgoingScenario 1In questo scenario i valori delle...
Segue il confronto tra i campioni ottenuti con la formula standard e quella oggetto di studioin base alla ‘densità di prob...
Scenario 2In questo scenario i valori delle costanti sono:         α = 1, β = 0.25, γ = 0.125, θ = 0.125quindi la formula ...
arriva a discapito della banda: infatti il numero dei RTO scaduti, quindi delle ritrasmissioniè maggiore rispetto alla for...
Scenario 3In questo scenario i valori delle costanti sono:         α = 1, β = 1, γ = 0.5, θ = 0.5quindi la formula è:     ...
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp
Upcoming SlideShare
Loading in …5
×

Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp

659 views

Published on

Tesi formato pdf

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
659
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp

  1. 1. UNIVERSITÀ DEGLI STUDI DI TRIESTE FACOLTÀ DI INGEGNERIA Tesi di Laurea Specialistica in INGEGNERIA INFORMATICA PROGETTO E REALIZZAZIONE DI UN KERNEL LINUX PER IL CONTROLLO DINAMICO DEGLI STIMATORI DI PERDITA SEGMENTI IN TCPRelatore LaureandoChiar.mo Prof. Alberto Bartoli Myrteza Kertusha Anno Accademico 2011/2012
  2. 2. INDICEIndice delle figure .............................................................................................................................. 3Introduzione ....................................................................................................................................... 41 Architettura ..................................................................................................................................... 6 1.1 Registrazione RTT e RTO ........................................................................................................... 6 1.1.1 Utilizzo ............................................................................................................................... 7 1.2 Formula aggiornamento dinamico RTO.................................................................................... 8 1.2.1 Utilizzo ............................................................................................................................... 9 1.2.1.1 Gestione formula per calcolo RTO............................................................................. 9 1.2.1.2 Associazione ‘formula-connessione’ ......................................................................... 92 Implementazione .......................................................................................................................... 11 2.1 Registrazione RTT e RTO ......................................................................................................... 11 2.1.1 Contesto kernel ............................................................................................................... 11 2.1.1.1 Kernel built-in .......................................................................................................... 12 2.1.1.2 Modulo kernel ......................................................................................................... 15 2.1.2 Contesto utente............................................................................................................... 17 2.1.2.1 Skeleton contesto kernel ......................................................................................... 17 2.1.3 Descrizione grafica .......................................................................................................... 18 2.2 Formula RTO ........................................................................................................................... 20 2.2.1 Contesto kernel ............................................................................................................... 20 2.2.1.1 Kernel built-in .......................................................................................................... 20 2.2.1.2 Modulo kernel ......................................................................................................... 23 2.2.2 Contesto utente............................................................................................................... 24 2.3 Scelte implementative ............................................................................................................ 25 2.3.1 Interfaccia tra I due contesti ........................................................................................... 26 2.3.2 Accesso concorrenziale ................................................................................................... 27 2.3.3 Rilascio delle risorse ........................................................................................................ 283 Benchmark .................................................................................................................................... 32 3.1 Impatto modifiche apportate allo stack TCP .......................................................................... 33 1
  3. 3. 3.2 Impatto sessione di registrazione ........................................................................................... 364 Casi di studio ................................................................................................................................. 39 4.1 Formula ‘chu’ .......................................................................................................................... 40 4.1.1 Connessioni outgoing ...................................................................................................... 42 4.1.2 Connessioni incoming...................................................................................................... 49 4.1.3 Riassunto ed osservazioni ............................................................................................... 52 4.2 Formula ‘speedy’ .................................................................................................................... 53 4.2.1 Connessioni outgoing ...................................................................................................... 55 4.2.2 Riassunto ed osservazioni ............................................................................................... 61Conclusioni ....................................................................................................................................... 63Referenze ......................................................................................................................................... 65Appendice ........................................................................................................................................ 66 2
  4. 4. INDICE DELLE FIGUREFigura 2.1 Strutture di supporto alla registrazione RTT e RTO .................................................................................... 12Figura 2.2 Associazione tra strutture di supporto alla registrazione e quella sock ..................................................... 13Figura 2.3 Sessione di registrazione RTT e RTO. Buffer i – 2: già elaborato; i – 1: pieno, da elaborare; i + 2:ancora da riempire ...................................................................................................................................................... 19Figura 2.4 Associazione tra strutture di supporto all’aggiornamento dinamico di RTO e quella sock ........................ 21Figura 2.5 Rilascio risorse relative ad una sessione di registrazione (1 di 2) ............................................................... 30Figura 2.6 Rilascio risorse relative ad una sessione di registrazione (2 di 2) ............................................................... 31Figura 3.1 Ambiente di test. Macchina A (Vbox): kernel NON modificato; macchina B (Vbox): kernelmodificato; macchina C: server in ascolto, in esecuzione sulla macchina ospite (Windows7) .................................... 34Figura 3.2 Confronto in base alla “durata di upload” ................................................................................................. 35Figura 3.3 Ambiente di test. Macchina A (Vbox): kernel modificato; macchina B (Vbox): kernel modificatosessione di registrazione in atto; macchina C: server porta 80 in locale ..................................................................... 37Figura 3.4 Confronto in base alla “durata di upload” ............................................................................................... 388Figura 4.1 Ambiente di test ......................................................................................................................................... 42Figura 4.2 Confronto in base alla “durata di upload” ................................................................................................. 43Figura 4.3 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa” ........................................... 43Figura 4.4 Confronto in base alla “durata di upload” e “syn inviati” .......................................................................... 44Figura 4.5 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa” ........................................... 45Figura 4.6 Ambiente di test ......................................................................................................................................... 46Figura 4.7 Confronto in base alla “durata di upload” e “syn inviati” .......................................................................... 47Figura 4.8 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa” ........................................... 48Figura 4.9 Confronto in base alla “durata di download” e “synack inviati” ................................................................ 50Figura 4.10 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa” ......................................... 51Figura 4.11 Riassunto risultati..................................................................................................................................... 52Figura 4.12 Ambiente di test ....................................................................................................................................... 54Figura 4.13 Confronto in base alla “durata di upload” e “rto scaduti” ....................................................................... 55Figura 4.14 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa” ......................................... 56Figura 4.15 Confronto in base alla “durata di upload” e “rto scaduti” ....................................................................... 57Figura 4.16 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa” ......................................... 58Figura 4.17 Confronto in base alla “durata di upload” e “rto scaduti” ....................................................................... 59Figura 4.18 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa” ......................................... 60Figura 4.19 Riassunto risultati..................................................................................................................................... 61 3
  5. 5. INTRODUZIONETCP è un protocollo affidabile, che garantisce la trasmissione dei dati tra due endpointcostituenti la connessione. Tale obiettivo viene raggiunto attuando delle politiche diritrasmissione. L’endpoint trasmittente, in mancanza di conferma dell’avvenuta ricezionedei dati dall’endpoint remoto entro un tempo prestabilito (a causa di ritardi di rete o diperdita), deve ritrasmettere i dati non ancora confermati. Essi vengono inviati nuovamenteallo scadere di RTO (Retransmission Timeout), grandezza stimata del timeout diritrasmissione ed aggiornata dinamicamente anche in base a RTT (Round Trip Time),grandezza misurata del tempo dandata e ritorno.Le formule per l’aggiornamento dinamico di RTO utilizzate nei sistemi operativi odiernisono quelle che col tempo si sono dimostrate migliori nei contesti più generici. In alcunicampi particolari, tuttavia, in funzione dellutilizzo (data streaming, command protocol,ecc) oppure del mezzo di comunicazione (intranet vs internet, wired vs wireless, ecc),formule alternative possono portare a risultati migliori. Tale formula per poter essereutilizzata in un contesto reale, deve però essere sottoposta ad un processo iterativo dianalisi e test, al fine di valutare la sua efficacia e/o efficienza.In questa tesi è stata costruita un infrastruttura basata su kernel Linux che consente di: • ottenere informazioni sui valori di RTT e RTO relativi ad una connessione • modificare la formula per l’aggiornamento dinamico di RTO: essa può essere associata ad una singola connessione oppure a tutto il sistemaGrazie all’infrastruttura oggetto di questa tesi, è possibile modificare la formula per ilcalcolo di RTO e testarne immediatamente gli effetti introdotti nella comunicazione, senzadover far ripartire il sistema operativo, o tanto meno ricompilare il kernel. Volendoanalizzare più in dettaglio suddetti effetti si può accedere ai valori RTT e RTO relativi aduna connessione TCP.Il primo capitolo, Architettura, offre una panoramica generale dell’infrastruttura proposta.Ulteriori dettagli realizzativi seguono nel secondo capitolo, Implementazione. La 4
  6. 6. valuazione dell’impatto dovuto alle modifiche apportate, sulle performance del sistema èl’argomento del terzo capitolo, Benchmark. Nel quarto capitolo, Casi di studio, vengonoanalizzati due casi di studio utilizzando l’infrastruttura proposta. 5
  7. 7. 1. ARCHITETTURADa un punto di vista architetturale l’infrastruttura proposta è composta da due sottosistemi.Al primo spetta il compito di bufferizzare i valori RTT e RTO in strutture dati in memoria,nel contesto kernel, quindi la loro esportazione in quello utente per ulteriori elaborazioni. Ilsecondo sottosistema invece, riguarda la formula per l’aggiornamento dinamico di RTO:come crearle e/o modificarle, aggiungerle nel sistema ed infine associarle alle connessioniTCP. Nonostante lo scopo del primo sottosistema è quello di rendere disponibili utiliinformazioni al secondo, ognuno dei due può esistere indipendentemente dall’altro.1.1 Registrazione RTT e RTOI valori di RTT e RTO vengono calcolati quindi aggiornati nel contesto kernel. Lecondizioni per le quali questo avviene sono le seguenti: • avvenuta ricezione di un pacchetto o insieme di nel qual caso RTT e RTO vengono aggiornate • timeout d’avvenuta ricezione per un pacchetto o insieme di nel qual caso RTO viene aggiornata • connessione appena stabilita nel qual caso RTO viene aggiornata • errore ‘host unreachable’ pervenuto dal modulo icmp nel qual caso RTO viene aggiornataOgni volta che una delle condizioni di sopra ha luogo, i valori vengono memorizzati nelleapposite strutture dati in memoria. La memorizzazione riguarda sia RTT che RTOindipendentemente dalla condizione verificata. Può essere pensata come un’istantanea diRTT e RTO, il cui scatto avviene a fronte di una delle condizioni di cui sopra. Assieme ai 6
  8. 8. valori di RTT e RTO vengono memorizzati listante temporale e il tipo di condizioneverificatasi al fine poter distinguere successivamente nella fase di elaborazione.Con lutilizzo di un modulo kernel i valori bufferizzati vengono resi disponibili al contestoutente. Pertanto vengono creati, durante la fase di boot, una serie di device il cui scopo èproprio quello di accedere alle funzionalità del modulo kernel. Per accedere ai datid’interesse è stato implementato un ulteriore layer al fine di semplificare quanto piùpossibile il processo da parte delloperatore. Lunico compito spettante al programmatore èappunto lelaborazione stessa dei dati.1.1.1 UtilizzoSegue una breve descrizione, di una sequenza d’operazioni da eseguire per accedere aivalori RTT e RTO relativi ad una connessione. • apertura device lesecuzione di questa operazione richiede le seguenti informazioni passate a loro volta tramite una struttura come parametro in ingresso: o device che verrà utilizzato come punto di ingresso al contesto kernel • inizio sessione di registrazione il concetto di sessione di registrazione è inteso come "registrazione dati in corso". Linizio della sessione richiede le seguenti informazioni passate a loro volta tramite una struttura come parametro in ingresso: o connessione tcp identificata con la coppia [(ip:port)src, (ip:port)dst] ai quali valori di RTT e RTO si dichiara l’interesse o callback 7
  9. 9. “un puntatore di funzione” nel contesto utente, che viene chiamato dal contesto kernel in presenza di dati nuovi da elaborare Nel caso l’operazione avesse esito positivo la connessione scelta non sarà più disponibile per un’altra sessione di registrazione se non alla fine di quella già in corso • fine sessione di registrazione alla fine di questa operazione, la connessione scelta diventa disponibile per una successiva sessione di registrazione • chiusura driverLa 2° e 3° operazione, ovvero inizio e fine di una sessione di registrazione, possono esserereiterate pur utilizzando lo stesso device aperto, mantenendo però l’ordine. In questo modoè possibile attuare più di una sessione in sequenza. Da evidenziare il fatto che la sessioneattiva ha l’esclusività sul device: non è possibile attuare una ulteriore se non alla fine diquella già in corso. Per scelta, è stato preferito la semplicità di utilizzo (apertura di unulteriore driver) alla complesità richiesta (demultiplexing, api più complesse).1.2 Formula aggiornamento dinamico RTOIl secondo sottosistema riguarda la formula per l’aggiornamento dinamico di RTO. Essoconsente di creare e/o modificare, aggiungere e/o rimuovere le formule dal sistema. Inoltre,è possibile impostare una formula di default (utilizzata da tutte le connessioni create daquel momento in poi) oppure a scelta, specificatamente ad una connessione.La formula per il calcolo di RTO utilizzata dal kernel è proposta nella forma di unafunzione. Tale funzione è presente nel codice kernel, quindi apportare modifiche equivalead una ricompilazione dello stesso. Purtroppo questa operazione richiede un tempo diesecuzione non indifferente. 8
  10. 10. Con lo strumento proposto in questa tesi, la formula per l’aggiornamento dinamico di RTOviene caricata sotto forma di un modulo kernel. In questo modo essa si può modificaresenza dover ricompilare il kernel. Nel kernel vi sono state apportate delle modifiche al finedi rendere disponibili tali moduli allo stack TCP. I moduli implementano le funzionalitàbasi tra le quali la funzione che appunto aggiorna il valore RTO. Tale funzione vienechiamata ogniqualvolta RTO viene aggiornata. La formula attualmente in uso nel kernel èstata implementata come modulo, caricato automaticamente in fase di boot del sistema.Utilizzando linterfaccia ioctl-sockopt è possibile associare una formula a scelta tra quelledisponibili nel sistema, ad una specifica connessione TCP. Infine utilizzando linterfacciasysfs si può impostare una formula tra quelle disponibili come default.1.2.1 UtilizzoLutilizzo della funzionalità offerta comprende da una parte la possibilità di modificare leformule e dallaltra quella di associare esse ad una specifica connessione a scelta.1.2.1.1 Gestione formula per calcolo RTOLa formula viene implementata nella forma di un modulo kernel. La creazione dellaformula quindi, equivale allimplementazione del modulo kernel. Laggiunta e la rimozioneinvece equivalgono all’inserimento ed alla rimozione di essa dalla lista dei modulidisponibili.Tramite l’interfaccia sysfs del kernel è possibile impostare una delle formule disponibilicome default. Ogni connessione nuova, se non diversamente specificato, utilizzerà laformula di default per il calcolo dinamico di RTO.1.2.1.2 Associazione ‘formula 2 connessione’L’associazione di una specifica formula per l’aggiornamento dinamico di RTO ad unaconnessione è realizzabile tramite l’utilizzo di due diverse interfacce. La prima interfacciaè quella tipica per la configurazione delle connessioni tcp (setsockopt). Chiamare la suddetta 9
  11. 11. syscall con il nome della formula scelta fa si che da quel istante in poi la, i valori di RTOvengano calcolati con quella formula. E’ il caso di evidenziare che tale syscall implica chela connessione TCP sulla quale si vuole intervenire è stata creata dal processo che staeffettuando la chiamata stessa. Quest’ultimo è dovuto al fatto che il parametro passato iningresso alla setsockopt (file descriptor con la quale si identifica la connessione TCP), non èdato a sapere se non nel contesto del processo dove la connessione stessa è stata creata.Come seconda interfaccia, si può utilizzare quella per la sessione di registrazione dei valoridi RTT e RTO. Una volta aperto il device ed iniziata la sessione di registrazione, si puòutilizzare la funzionalità del device per l’impostazione di una formula specificatamente aduna connessione TCP. In questo modo si ha la possibilità di intervenire anche su unaconnessione creata da un altro processo. 10
  12. 12. 2. IMPLEMENTAZIONEIn questo capitolo viene fatta una descrizione più dettagliata dell’infrastruttura proposta.Riallaciandosi all’aspetto funzionale, verrà puntata la lente d’ingrandimento su ognuno deidue sottosistemi. La loro descrizione riguarderà l’implementazione sia nel contesto kernelche quello utente. Per poi proseguire con una discussione su varie scelte implementativefatte.2.1 Registrazione RTT e RTOLa registrazione dei valori di RTT e RTO avviene sia nel contesto kernel che quelloutente. Nel contesto kernel, l’implementazione segue delle linee guida con un occhio diriguardo alla prestazione ed alla stabilità. Un possibile errore in questo contestorenderebbe il tutto instabile ed addirittura inutilizzabile. Nel contesto utente invece,l’obiettivo è stato quello di fornire api ben progettate e semplici da utilizzare.2.1.1 Contesto kernelL’implementazione nel contesto kernel riguarda una componente “statica”, di supporto perl’intera infrastruttura. In questa categoria fanno parte tutte le modifiche apportate nellastruttura del kernel che richiedono la sua ricompilazione. Le modifiche apportate allastruttura sock, i punti individuati nel kernel ove le condizioni si verificano ne fanno parte.La seconda categoria riguarda la parte “dinamica”, le cui modifiche non necessitano laricompilazione. Il modulo che si interfaccia con il contesto utente per l’esportazione deidati ne fa parte. 11
  13. 13. 2.1.1.1 Kernel built2inIl termine built-in rende meglio l’idea sull’argomento di questo paragrafo. Infatti riguardatutte le modifiche integrate nel kernel stesso. Le modifiche fanno da ponte tra il kernel e lanuova infrastruttura. • strutture nuove aggiunte La struttura zsample_buffer è il buffer dove i valori RTT e RTO vengono bufferizzati. Essa ospita inoltre, delle variabili con le quali tra i due contesti viene attuato del protocollo di comunicazione. La struttura zsample_buffer_holder è un insieme di zsample_buffer. La suddivisione della memoria disponibile in tanti buffer diminuisce la possibilità di problemi dovuti all’accesso concorrenziale. Figura 2.1 Strutture di supporto alla registrazione RTT e RTO La struttura zsample_sniff_session contiene tutto il necessario per una sessione di registrazione. Essa contiene un riferimento all’array di buffer ove i valori RTT e RTO vongono memorizzati. L’accesso al modulo è reso possibile con un 12
  14. 14. ‘puntatore di funzione‘ (take_sample). Infine, con la presenza di variabili flag, il rilascio della memoria relativa alla sessione viene fatto in tutta sicurezza.• associazione tra la connessione TCP e le strutture nuove la struttura di supporto, zsample_sniff_session, viene associata a quella sock indirettamente tramite una ulteriore, la zsample_sock_sniff_session_wrapper. In questo modo si disaccoppia il corso d’azione tra lo stack TCP ed il modulo kernel. Il processo che si occupa del rilascio delle risorse utilizza appunto questa struttura per riconoscere se una connessione è chiusa, quindi rilasciare la relativa memoria occupata da sessioni di registrazione. Figura 2.2 Associazione tra strutture di supporto alla registrazione e quella sock Le modifiche apportate alla struttura sock riguardano sia la registrazione che l’utilizzo della formula per l’aggiornamento dinamico di RTO. I campi che riguardano la registrazione sono necessari per la bufferizzazione e per il rilascio 13
  15. 15. delle relative risorse. Invece i campi che riguardano l’aggiornamento dinamico forniscono delle informazioni utili concernenti la connessione durante la fase 3WHS.• inserite nel codice kernel le chiamate per la bufferizzazione dei dati nel codice del kernel, nei punti dove le condizioni di aggiornamento di RTT e/o RTO hanno luogo, sono state apportate delle funzioni. Tramite esse il corso d’esecuzione viene instradato verso l’infrastruttura proposta. Ogni chiamata ha come parametri la struttura sock appartenente ed il tipo di condizione verificata.• sessioni di registrazione onde permettere la registrazione dei valori RTT e RTO sono state implementate delle api visibili solo nel contesto kernel (tipicamente i moduli). o int take_sample(struct sock *sk, int origin, void *data) la funzione con la quale il corso d’azione dello stack viene instradato nel modulo kernel. L’implementazione di questa api consiste in una serie opportuni controlli affinche i riferimenti alle varie strutture siano validi. Successivamente viene fatta la chiamata al ‘puntatore di funzione’ (vedasi zsample_sniff_session) definita nel modulo kernel. Tale funzione viene chiamata ogni volta che una delle condizioni d’aggiornamento di RTT e RTO ha luogo. o struct zsample_sniff_session* connectionSearch(unsigned int saddr, unsigned int daddr, unsigned short sport, unsigned short dport, int *ret) è la funzione che si occupa di individuare tra le connessioni attualmente stabilite, quella identificata dai parametri in ingresso. Tale funzione viene chiamata dal modulo kernel quando l’utente indica interesse nel registrare i valori RTT e RTO di una connessione TCP. Nel caso la connessione venisse individuate, la struttura zsample_sniff_session viene creata, quindi ritornata come parametro di return. Qualora la connessione non venisse 14
  16. 16. individuata oppure non fosse disponibile in quanto già utilizzata in un’altra sessione il parametro ritornato è NULL. o int connectionRelease(struct zsample_sniff_session *rttKernel) tale funzione termina la sessione di registrazione. Successivamente la connessione diventa disponibili a future sessioni e le relative risorse vengono liberate. Le condizioni per cui una sessione di registrazione viene terminata sono per scelta dell’applicativo nel contesto utente oppure perchè la connessione TCP viene chiusa. • processo di rilascio delle risorse è il processo che si occupa del rilascio delle risorse dopo che una sessione di registrazione viene terminata. Esso viene fatto partire già durante il boot del sistema. Il suo compito è quello di mantenere traccia in una lista globale, di tutte le strutture create come supporto alle sessioni di registrazione. Ad ogni sessione nuova corrisponde un inserimento della relativa struttura nella lista globale (vedasi connectionSearch). Rispettivamente ad ogni sessione terminata la relativa struttura viene segnata come ‘da rimuovere’ (vedasi connectionRelease). Il rilascio della memoria viene fatto in modalità deferred, ovvero posticipata per eliminare l’overhead dovuto alla protezione dell’accesso concorrenziale tra lo stack tcp ed il modulo kernel.2.1.1.2 Modulo kernelLe funzionalità integrate nel kernel vengono esposte al contesto utente con l’utilizzo deimoduli kernel. Il loro compito è quello di interfacciarsi da una parte con lo stack TCP edall’altra con il contesto utente. Con il contesto utente tale interfacciamento è resopossibile tramite un device a caratteri: infatti durante la fase di boot del sistema vengonocreati una serie di device, come specificato in /etc/rc.d/rc.modules. Invece dallo stack TCP ilmodulo è raggiungibile tramite le api introdotte nella sezione precedente (vedasitake_sample). Tale modulo viene caricato già nella fase di boot del sistema, come specificato 15
  17. 17. in /etc/rc.d/rc.modules.Interfaccia con il contesto kernelIl modulo implementa la funzione take_sample (distinta da quella dello stesso nomeintegrata nel kernel) che svolge effettivamente l’operazione di bufferizzazione dei valoriRTT e RTO. L’implementazione volutamente viene fatta nel modulo affinche siafacilmente modificabile. E’ compito suo bufferizzare i dati opportunamente e soprattuttonotificare il contesto utente in caso si verifichi una condizione particolare (es. bufferriempito ecc). Quando una sessione di registrazione inizia, uno dei parametri della relativastruttura è appunto un puntatore di funzione a questa chiamata.Interfaccia con il contesto utenteL’accesso al modulo, quindi al contesto kernel viene fatto utilizzando un device a caratteri.Perciò per poter utilizzare le funzionalità offerte, in primis il device va aperto. Seguendo lelinee guida dell’interfaccia ioctl tipica dei device, sono state implementate tutte lefunzionalità richieste. Per quanto riguarda l’esportazione dei dati tra i due contesti essoviene fatto tramite il memory mapping, ovvero una zona di memoria condivisa tra i duecontesti. In questo modo si risparmia una copia dei dati tra i due contesti. Segue una brevedescrizione delle api ioctl disponibili, in base al parametro ioctl_cmd: • SESSION_ON_IOCTL viene fatta la ricerca, tra quelle disponibili, sulla connessione TCP come dai parametri in ingresso identificata. In caso tale ricerca avesse esito positivo, una struttura (zsample_sniff_session) viene creata, pronta per l’uso. Alla struttura appena inizializzata, viene passato sotto forma di un ‘puntatore di funzione’ il riferimento alla funzione take_sample, ed anche l’oggetto wait_queue_head_t col quale viene segnalato il contesto utente della ‘presenza di dati da elaborare’. • WAIT_DATA_IOCTL la chiamata blocca fino al massimo di 1 sec, in attesa di una segnalazione di ‘presenza di dati da elaborare’ dal modulo kernel. Se entro tale tempo la segnalazione non perviene, essa ritorna al chiamante ed è compito di quest’ultimo ritentare la chiamata. 16
  18. 18. Nel caso la connessione TCP, oggetto della sessione di registrazione, venisse chiusa, questo evento è segnalato al contesto utente. • GET_RTO_FORMULA_IOCTL / SET_RTO_FORMULA_IOCTL queste ioctl sono utili nel caso si volesse intervenire sulla formula per l’aggiornamento dinamico di RTO, relative ad una connessione TCP creata da un altro processo. • SESSION_OFF_IOCTL la sessione va in ogni caso terminata, sia per iniziativa dell’applicativo nel contesto utente oppure perchè la connessione viene chiusa. Essa svolge i seguenti compiti: o rilascia la struttura dati relativa alla sessione di registrazione o la connessione TCP viene segnata come libera, quindi candidata ad eventuali future sessioni di registrazione2.1.2 Contesto utenteIl contesto utente si interfaccia col modulo kernel tramite un device a caratteri.Interfacciarsi col modulo implica l’esecuzione delle seguenti operazioni: • apertura del device • memory mapping • estrazione dei dati dal contesto kernel • chiusura del deviceOnde rendere più semplice il compito al programmatore è stato implementato uno skeleton,nella forma di un layer superiore. Si occupa di eseguire le operazioni di cui sopra,nascondendo i dettagli e proponendo un’interfaccia più semplice.2.1.2.1 Skeleton contesto utenteLa struttura rtt_ctrl, creata come supporto all’infrastruttura, raggruppa tutto il necessario.Riempita opportunatamente (device da utilizzare, puntatore di funzione da richiamare ecc)essa verrà utilizzata successivamente come parametro di tutte le api. Uno dei parametri di 17
  19. 19. tale struttura è il ‘puntatore di funzione’ che verrà chiamato in presenza di dati daelaborare. Infatti, il thread creato dallo skeleton, che si occupa di estrarre i dati dal modulokernel, chiamerà tale puntatore di funzione per rendere disponibili al programmatore i dati.Ovviamente l’implementazione di questa funzione spetta al programmatore stesso. Tipiciutilizzi sono: salvataggio in file, plot del grafico in tempo reale e via dicendo.Le api begin_session e end_session possono essere chiamate in successione, pur mantenendoaperto anche lo stesso device. In tutte le api il parametro err_code è di tipo ‘in uscita’ e haun significato particolare in funzione dell’api stessa. • int open_device(rtt_ctrl* ctrl, int *err_code); • int close_device(rtt_ctrl* ctrl, int *err_code); • int begin_session(rtt_ctrl* ctrl, int *err_code); • int end_session(rtt_ctrl* ctrl, int *err_code);Le seguenti api vengono riportate per completezza, nonostante riguardano la parte che sioccupa della formula per l’aggiornamento dinamico di RTO. Le funzionalità offerte sonofacilmente intuibili dalle denomizazioni stesse. • int get_available_rto_formula(char *holder, int max_len); • int get_current_sniffing_connection_rto_formula(char *holder, int max_len); • int set_current_sniffing_connection_rto_formula(char *holder);2.1.3 Descrizione graficaIl processo che si occupa della registrazione dei valori RTT e RTO viene eseguito sia nelcontesto kernel che quello utente. La generazione degli eventi, il passaggio tra i duecontesti rendono il tutto non facilmente intuibile. Con la seguente descrizione grafica ed iseguenti commenti sui vari passaggi si cerca appunto di rendere più apprensibile taleprocesso. 18
  20. 20. Figura 2.3 Sessione di registrazione RTT e RTO. Buffer i – 2: già elaborato; i – 1: pieno, da elaborare; i + 2: ancora dariempire1 L’applicativo nel contesto utente dopo aver aperto il device, selezionato la connessione TCPd’interesse, effettua una chiamata ioctl bloccante-sincrona con timeout2 La chiamata ioctl di cui sopra, ritorna al thread chiamante in presenza di dati da elaborare oppure pertimeout. In ambedue i casi l’applicativo ritenta di nuovo la chiamata ioctl (fin tanto che non vienepredisposto altrimenti es. CTRL-C od altro)3 Nel frattempo eventuali condizioni verificate nello stack TCP (ack ricevuti, timeout scaduti) generanoi valori RTT e RTO che vengono bufferizzati4 Una volta che uno dei buffer viene riempito lo stesso stack TCP segnala il thread chiamante dellapresenza di dati da elaborare5 A questo punto il thread chiamante a cavallo tra i contesti utente e kernel rientra da quest’ultimo inquello utente6 Una volta ritornato al thread chiamante, riconoscendo la presenza nel buffer circolare di dati daelaborare, il thread si presta all’elaborazione dei dati come dalla logica richiesta (salvataggio in un file,esecuzione di statistiche storiche, visualizzazione del grafico in tempo reale ecc). Da notare come in questafase la prossima chiamata ioctl viene effettuata solo dopo che tutti i dati (anche quelli che eventualmentearrivano nel frattempo) sono stati elaborati, onde eliminare quanto più possibile i cross-boundaries (lechiamate ioctl). 19
  21. 21. 2.2 Formula RTOLa formula per l’aggiornamento dinamico di RTO è implementata nella forma di unmodulo kernel. La sua implementazione segue le regole generali di un modulo kernel(entry e exit point, ecc), ed inoltre implementa le api necessarie all’infrastruttura proposta.2.2.1 Contesto kernelNel contesto kernel l’implementazione riguarda una componente “statica” che consentel’interfacciarsi tra lo stack TCP ed i moduli kernel tramite i quali le formule stesse sonoimplementate. Esso concerne tutte le modifiche apportate nella struttura del kernel cherichiedono la ricompilazione dello stesso. Le modifiche apportate alla struttura sock, i puntiindividuati nel kernel dove la formula viene selezionata per la prima volta, dove vienescelta una diversa formula rispetto a quella di default, dove le chiamate al modulo vengonofatte ne fanno parte. L’altro componente riguarda la parte “dinamica” le cui modifiche nonnecessitano la ricompilazione del kernel. Esso concerne i moduli kernel per le formule.2.2.1.1 Kernel built2inIl termine built-in rende meglio l’idea sull’argomento di questo paragrafo. Infatti riguardatutte le modifiche integrate nel kernel stesso. • strutture nuove aggiunte la struttura nuova aggiunta tcp_rto_formula_ops, oltre ai vari campi tipici dei moduli kernel (es. owner) è composta da una serie di ‘puntatori di funzione’. 20
  22. 22. Figura 2.4 Associazione tra strutture di supporto all’aggiornamento dinamico di RTO e quella sock Alla creazione di una struttura sock segue anche un’opportuna inizializzazione del modulo che calcolerà i valori di RTO. E’ appunto tramite questi puntatori, che lo stack TCP raggiunge il modulo kernel.• chiamate inserite nel codice dello stack TCP in vari punti dello stack TCP sono state aggiunte le chiamate verso i moduli kernel. In primis, alla creazione di una struttura sock è stata aggiunta della logica che opportunamente associa la connessione tcp al modulo (*init). In questa fase d’inizializzazione viene intanto aumentata la variabile ref_cnt del modulo kernel il cui compito è quello di impedire che il modulo possa essere rimosso dal sistema 21
  23. 23. mentre in uso. Poi vengono inizializzate una serie di costanti relativa alla formula RTO. Infine la struttura nuova rappresentante il modulo viene aggiunta come referenza a quella sock rendendosi cosi disponibile all’utilizzo. Nel kernel, ove RTO viene aggiornata, il corso d’azione viene instradato tramite i puntatori di funzione, al modulo kernel rappresentato dalla struttura referenziata. Le condizioni per le quali questo si verifica sono le seguenti: o ack di un pacchetto o insieme di o RTO scaduto o connessione appena stabilita o evento di ‘host unreachable’ pervenuto dal modulo icmp• modulo integrato nel kernel avendo modificato opportunamente in vari punti lo stack TCP, si vuole altrettanto fare il modo che il sistema sia comunque in una situazione ben definita. Infatti nel kernel è stato aggiunto un modulo che implementa una formula di default, caricata durante il boot del sistema. Essa implementa in dettaglio quanto già presente nel kernel prima delle modifiche. Quindi tranne per il fatto che il corso d’azione viene instradato nel modulo, l’implementazione di default non ha alcuna differenza rispetto a quella precedentemente implementata dal kernel prima delle modifiche.• chiamate per la gestione delle formule una volta che una formula rto viene inserita nel kernel essa necessita qualche forma di gestione. Per questo nel kernel sono state apportate delle modifiche onde consentire: o impostare una formula come globale o di default o impostare una formula per una specifica connessione TCP Nel primo caso viene utilizzata l’interfaccia sysctl del kernel. Invece l’associazione di una formula ad una connessione TCP è resa possibile tramite l’interfaccia ioctl stessa dei socket. 22
  24. 24. 2.2.1.2 Modulo kernelI moduli kernel che aggiornano RTO devono implementare delle api con signature bendefinite. Per iniziare, api module_init ed module_exit le quali vengono chiamaterispettivamente al caricamento ed alla rimozione del modulo stesso. Le seguenti api inveceriguardano l’implementazione della logica per l’aggiornamento dinamico di RTO: • init • release • tcp_calc_synack_rto • tcp_set_rto • tcp_set_rttLa funzione init è chiamata la prima volta che una connessione vuole utilizzare il moduloin questione. Il modulo incrementa il valore ref_cnt affinche esso non possa essererimosso dal sistema mentre in uso. Nel nostro caso nella funzione init vengono inizializzatevariabili della struttura sock con le quali si controllano i valori massimi, minimi ed inizialidi RTO, attualmente costanti nel kernel. Altre possibili operazioni possono essereinizializzazioni di eventuale memoria da utilizzare, possibili riferimenti aggiornati ecc.La funzione release è speculare alla init. Essa è chiamata quando la connessione TCP nonutilizzerà più il modulo in questione. Va evidenziato, che questa chiamata decrementaanche la variabile ref_cnt del modulo, rendendolo cosi un possibile candidato allarimozione. Per questo motivo si deve essere assolutamente sicuri che il modulo non verràin alcun modo più utilizzato. Rispettivamente, possibili operazioni sono il rilascio dieventuale memoria occupata, riferimenti aggiornati ecc.Una connessione TCP appena creata e prima di essere stabilita si trova in uno dei seguentistati in base al tipo: • connessione outgoing ovvero in uscita (connect) stato TCP_SYN_SENT, intesa come ‘inviato un pacchetto SYN, quindi in attesa del relativo ACK’ 23
  25. 25. • connessione incoming ovvero in ingresso (accept) stato TCP_SYN_RECV, intesa come ‘inviato ACK ad un pacchetto SYN pervenuto, quindi in attesa del relativo ACK’A differenza delle altre, le connessioni incoming da un punto di vista delle strutture dati disupporto, necessitano di una diversa implementazione. Infatti il kernel durante lo statoTCP_SYN_RECV implementa la logica opportuna con una struttura (request_sock) dati disupporto più “leggera” dal punto di vista della memoria. Quindi il modulo kernel esportadue funzioni per il calcolo dinamico di RTO: una per le connessioni (sia incoming cheoutgoing) una volta stabilite ed un’altra per le connessioni incoming nella faseTCP_SYN_RECV ovvero prima che esse siano stabilite.La funzione tcp_calc_synack_rto viene utilizzata per aggiornare il valore di RTO per unaconnessione incoming non ancora stabilita. La connessione TCP entra in questo statoappena risponde col proprio ACK ad un pacchetto SYN in ingresso. Rimane in questo statofinche non riceve l’ACK relativo dall’altra estremità, dopo il quale la connessione si spostanello stato TCP_ESTABLISHED.La funzione tcp_set_rto viene utilizzata per aggiornare il valore di RTO per unaconnessione TCP in tutti gli altri casi tranne quello precedente.La funzione tcp_set_rtt viene utilizzata per aggiornare il valore di RTT nella strutturatcp_sock. Tale funzione è chiamata dallo stack quando un pacchetto o insieme di vieneconfermato. In questo modo si ha la possibilità di accedere ai valori RTT nel contesto delmodulo kernel.2.2.2 Contesto utenteL’interazione tra il contesto utente ed i moduli è riassunta nel loro caricamento erimozione. In Linux con l’utilizzo di comandi shell è possibile eseguire tali operazioni: • caricamento - loading 24
  26. 26. root# insmod nome_formula.ko • rimozione - unloading root# rmmod nome_formulaUna volta caricati nel sistema, i moduli sono posti in una lista globale. Tra le formuledisponibili una sarà quella di default, ovvero la formula che ogni connessione TCPutilizzerà se non diversamente specificato. Tramite l’interfaccia sysfs è possibile avereinformazioni sulle formule disponibili nel sistema, leggere ed impostare quella di default: • tcp_rto_formula, r/w per leggere/impostare la formula rto di default cat /proc/sys/net/ipv4/tcp_rto_formula echo ‘aaa’ > /proc/sys/net/ipv4/tcp_rto_formula • tcp_available_rto_formula, r per reperire la lista delle formule disponibili cat /proc/sys/net/ipv4/tcp_available_rto_formulaPer impostare una particolare formula ad una specifica connessione vengono utilizzate lesyscall setsockopt/getsockopt. Esse sono delle chiamate simili alle ioctl, ma specifiche allesocket. • consente la lettura della formula associata alla connessione tcp (sockfd) getsockopt(sockfd, IPPROTO_TCP, TCP_RTO_FORMULA, (void*)&rto[0], (socklen_t*) &RTO_FORMULA_LEN) • consente l’associazione della formula “speedy” alla connessione tcp (sockfd) setsockopt(sockfd, IPPROTO_TCP, TCP_RTO_FORMULA, (void*)&”speedy”, strlen(&”speedy”))2.3 Scelte implementativeLa registrazione dei valori RTT e RTO è un processo che merita qualche approfondimentoin più. Esso opera a cavallo tra i due contesti ed inoltre ha un proprio impatto sulle risorsedi memoria e cpu. Quindi vanno indirizzate le seguenti problematiche: 25
  27. 27. • interfaccia per l’esportazione dei dati dal contesto kernel a quello utente • accesso concorrenziale ai dati tra il produttore (stack TCP) ed il consumatore (skeleton) • rilascio delle risorse utilizzate da sessioni di registrazione2.3.1 Interfaccia tra i due contestiI valori RTT e RTO memorizzati nel contesto kernel, affinche siano elaborati vannoesportati in quello utente. Nel contesto utente si ha accesso ad un insieme di librerie piùampio e ricco (basti pensare al floating point). Inoltre anche dal punto di vista dellaconoscenza di programmazione, il contesto utente raggiunge una audience più ampia. Taleprocesso non è una operazione semplice come ad esempio una copia dei dati da una zonadi memoria all’altra.In un SO Linux, possibili interfacce tra il contesto kernel e quello utente sono le seguenti(lista di certo non esaustiva): • file procfs, sysfs, configfs tipicamente utilizzate per la configurazione di parametri a livello kernel • socket tcp, udp e netlink tipicamente utilizzate per il passaggio di grandi quantità di dati. Da un punto di vista della programmazione sono alquanto complessi, in compenso però godono delle proprietà tipiche dei socket (caso tcp: l’affidabilità, caso udp: l’utilizzo dei datagram) • ioctl tipicamente tramite l’utilizzo di un device (a caratteri, blocchi ecc) • mmap memory mapping tipicamente utilizzati nei driver delle schede video per le alte prestazioni offerte. In compenso però richiedono degli sforzi in più dal punto di vista della programmazionePer adempiere ai compiti richiesti, fondamentalmente serve: • un meccanismo che possa informare il contesto utente in caso di presenza di dati • un meccanismo che consenta di esportare i dati dal contesto kernel a quello utente 26
  28. 28. La soluzione meglio adatta all’infrastruttura proposta è la seguente: • utilizzo di un device a caratteri che fornisce l’interfaccia ioctl tramite la quale si possono ottenere informazioni dal contesto kernel • utilizzo del mmap (memory mapping) per l’esportazione dei dati nel contesto utenteLa scelta di sopra è dettata nel primo caso dalla semplicità ovvero minimo sforzo possibileper ottenere le funzionalità richieste: tra i vari possibili device, il più semplice è quello acaratteri. Nel secondo caso invece la motivazione è la prestazione. Infatti con una diversainterfaccia (es. copy_to_user, socket etc) si andrebbe incontro ad una copia in più per ilpassaggio dei dati tra i due contesti. Il memory mapping invece, espone la zona di memoriadel kernel (tramite opportune api) al contesto utente come se fosse nel medesimo,eliminando quindi la necessità di una copia tra i due contesti.2.3.2 Accesso concorrenzialePer il passaggio dei dati tra i due contesti (kernel ed utente) viene utilizzata una zona dimemoria condivisa nella forma di un buffer. Essendo esso condiviso tra il produttore (cheaggiunge dati) ed il consumatore (che preleva dati) il problema dell’accesso concorrenzialeva indirizzato. Nel caso in questione si tratta di un unico produttore ed un unicoconsumatore il che semplifica di molto la situazione. Questo vorrebbe dire che il momentoin cui la contesa avrà luogo sarà solamente quando ambedue vi accedono al buffer. Nelcaso vi fossero più consumatori e/o produttori oltre alla contesa appena accennata visarebbe anche un’altra che dovrebbe serializzare i multipli produttori e/o consumatori chesiano. L’accesso serializzato al buffer è necessario in quanto nell’aggiornare gli indicidell’array sia il consumatore che il produttore devono essere sicuri di non interferire collavoro dell’altro. Infatti, la prassi in questi casi chiede che l’accesso vada protetto con deilock, ovvero il locking a livello kernel col minore overhead.Il produttore, nel nostro caso lo stack TCP, non si può permettere di aspettare che ilconsumatore finisca il suo lavoro. Questo introdurrebbe ritardi, anche minimi che siano, al 27
  29. 29. corso d’azione dello stack TCP. Tali ritardi non solo graverebbero sulla performance delsistema stesso, sull’andamento della connessione TCP, ma ‘sporcherebbero’ anche i valoriRTT e RTO stessi per i quali l’infrastruttura è stata costruita. Ne consegue che il corsod’azione del produttore (lo stack TCP) non deve essere interrotto in alcun modo,indipendentemente dalla velocità con la quale il consumatore possa elaborare i dati.Una possibile soluzione al problema appena posto viene dall’utilizzo del buffer circolare.In questo caso il produttore una volta raggiunto la fine del buffer, riparte dall’inizio. Nesegue come corollario che se la velocità con la quale il produttore inserisce in coda i dati èmaggiore di quella con la quale il consumatore li rimuove, i dati più vecchi verrebberosovrascritti con i più nuovi. Ovviamente in tale situazione il produttore sposterebbe anchel’indice del prossimo dato che il consumatore andrà a consumare e segnalare tale eventotramite un flag. Sarà compito del consumatore riconoscere dal flag questa situazione ecomportarsi di conseguenza.Con questa impostazione la contesa tra i due concorrenti non si verifica più: i corsid’azione di nessuno dei due viene interrotto in alcun modo dall’altro. Per quanto riguarda ilcaso peggiore, ovvero la velocità del produttore maggiore di quella del consumatore,l’impostazione proposta è sempre preferibile all’interruzione di uno dei due, in attesa dellafine del lavoro dell’altro. Purtroppo non esiste una soluzione al caso peggiore: non esisteun buffer infinito! Va detto però, che nel nostro caso, la velocità del produttoredifficilmente sarà maggiore di quella del consumatore anche se il sistema stesso fosse sottostress: gli eventi oggetti di studio non vengono generati con tale frequenza.2.3.3 Rilascio delle risorseLa zona di memoria condivisa tra il contesto kernel e quello utente è pursempre una risorsadi sistema: va comunque liberata dopo il suo utilizzo. Tale zona di memoria è condivisa tradue processi implicando che il rilascio da parte di uno potrebbe compromettere il corsod’azione dell’altro. Nel nostro caso uno dei due processi viene ospitato nel contesto kernelil che peggiora la situazione ulteriormente: un accesso di tipo reference ad una strutturaNULL porterebbe ad un crash del SO intero. 28
  30. 30. Proteggere l’accesso con un lock ha degli svantaggi. Lasciando stare per un attimo ilritardo introdotto al processo in attesa di rilascio del lock, preoccupa molto di più il bloccoindefinito. Si pensi ad esempio ad un ‘process kill’ a livello utente che già mantiene il locksulla struttura. Bloccherebbe indefinitivamente il processo nel contesto kernel in attesa delrilascio del lock. Anche nel caso in cui la chiusura della connessione TCP possa avere esitopositivo, le risorse (associate appunto alla connessione) non rilasciate, peserebbero a lungoandare sulla stabilità del SO stesso.La scelta fatta per l’infrastruttura proposta è quella del rilascio deferred ovvero posticipato.Le risorse vengono rilasciate solamente quando ambedue i processi dichiarano che non nefaranno più utilizzo. Ovviamente questo comporta della logica in più, ma consente anchedi eseguire l’operazione in tutta sicurezza. Per adempiere a questo compito l’infrastrutturaè stata dotata di una lista globale dove porre le strutture da rilasciare ed un processo che sioccuperà del loro rilascio. Sia la lista che il processo sono ospitati nel contesto kernel.Ogni struttura inizializzata viene per prima associata a quella sock, ed in più aggiunta comeriferimento in tale lista. In questo modo si ha accesso alla struttura anche quando sia laconnessione che il processo nel contesto utente siano terminati. A quel punto, ovveroquando la struttura viene segnalata da ambedue i processi come ‘da rilasciare’, il processopercorrendo la lista e riconoscendola la rimuove, quindi ne rilascia le sue risorseritornandole al SO.Sulla stessa connessione TCP, durante la sua vita, possono avere luogo diverse sessioni diregistrazione. Ognuna di queste sessioni avrà la propria struttura dati. Queste strutture datiperò, andranno rilasciate solamente quando la connessione tcp viene terminata ovveroquando la struttura sock verrà rilasciata dallo stack tcp stesso. Fintanto che la connessioneTCP è ancora attiva non si può avere la certezza (alla luce anche di possibili futuremodifiche del kernel) che nessun accesso verrà fatto dopo che le strutture della sessioneverranno rilasciate.La lista di cui si accennava poco fa, in realtà è un insieme di due tali. Una legata allo stackTCP, sock_wrapper_list e l’altra legata alle sessioni di registrazione, session_list. Segue unesempio ed una descrizione grafica onde descrivere meglio il meccanismo. 29
  31. 31. Con stack = 0 viene indicata una connessione TCP ancora attiva, che alla chiusura diventastack = 1. Lo stesso ragionamento vale anche per la variabile module riferita però almodulo kernel. Sia aa1 una struttura sock al quale corrispondono le sessioni aa1: 1 e aa1:2. La modifica apportata dallo stack TCP a fronte della chiusura della connessione, allastruttura in sock_wrapper_list viene propagata alle rispettive in session_list dal processoche si occupa del rilascio delle risorse.Figura 2.5 Rilascio risorse relative ad una sessione di registrazione (1 di 2)La propagazione dell’evento “connessione tcp chiusa” viene fatta in due fasi (ecco quindi lanecessità di due liste) proprio per disaccoppiare i corsi d’azione. La prima fase consiste 30
  32. 32. nella segnalazione da parte dello stack TCP di questo evento ponendo la variabile stack delrelativo elemento nella lista sock_wrapper_list a 1. In questo modo lo stack TCP non èobbligato a dover percorrere la session_list in cerca delle rispettive strutture riferite allesessioni. Infatti questo compito viene svolto dal processo di rilascio delle risorse.Solamente quando anche i moduli segnaleranno di aver preso visione, quindi che nonutilizzeranno più le strutture condivise allora inizia la seconda fase. Anche in questo caso èil processo di rilascio delle risorse che percorre la session_list liberando quindi le strutturenon più utilizzate.Figura 2. 6 Rilascio risorse relative ad una sessione di registrazione (2 di 2) 31
  33. 33. 3. BENCHMARKLe modifiche apportate nel kernel implicano indubbiamente un impatto sulla performancedel sistema. Alla struttura sock sono state aggiunte dei riferimenti a quella di supportoall’infrastruttura proposta. La struttura riferita riguarda sia l’aspetto ‘registrazione di RTTe RTO’ che ‘formula per l’aggiornamento dinamico di RTO’. Anche il processo che inbackground si occupa di rilasciare le risorse non più utilizzate, ha la propria componente diimpatto sulla performance.Quanto accennato riguarda il sistema nel suo intero indipendentemente dal fatto se unaregistrazione è attiva o meno. Qualora lo fosse, alle variabili che influiscono sullaperformance vanno aggiunte delle ulteriori. La struttura dati inizializzata per il passaggiodei dati tra il livello kernel ed utente. Inoltre il thread a livello utente che si occupa appuntodi esportare i dati dal contesto kernel, implica ulteriori risorse utlizzate sia di memoria checpu.Ai fini di un’analisi più semplificata, suddivideremo il problema in due. Il primoriguarderà solamente le modifiche apportate al kernel, lasciando fuori dall’equazione lasessione di registrazione. Verranno messi a confronto un kernel modificato ed uno non. Ilsecondo riguarderà solamente la sessione di registrazione. Verranno messi a confronto duekernel modificati, su uno dei quali però una sessione di registrazione è attiva.Modifiche apportate allo stack TCPLe seguenti operazioni verranno effettuate ogniqualvolta una delle condizioni diaggiornamento di RTO ha luogo: • accesso al modulo per aggiornare il valore di RTO • controllo se una sessione di registrazione è attivaNel caso la seconda operazione avesse esito positivo, altre, riguardanti la parte che sioccupa della registrazione dei valori RTT e RTO, ne seguirebbero. Esse non vengono presein considerazione ai fini dell’analisi in quanto hanno un impatto attribuibile allo stack TCP 32
  34. 34. solamente quando una sessione di registrazione è in atto. Ambedue le operazioni hanno unnumero ben definito di istruzioni, non soggetto di alcun ritardo dovuto ad altri processiquindi deterministiche.Sessione di registrazione attivaNel caso di una sessione di registrazione saranno prese in considerazione le seguentioperazioni: • memorizzazione dei valori RTT e RTO nelle opportune strutture dati • esportazione dei dati tra il contesto kernel e quello utenteIn questo caso abbiamo trascurato di proposito l’operazione effettuata dall’applicativo suidati esportati. Possiamo considerare il caso in cui i dati ottenuti vengono semplicementescartati (es. instradati in /dev/null) onde semplificare l’analisi.Per effettuare gli esperimenti sono stati costruiti due programmi di test. Un programma chesvolgerà il ruolo del client ed un altro quello del server. Ambedue i programmi tramite iparametri a linea di comando sono configurabili in base alla: • porta TCP sulla quale il server sarà in ascolto ovvero il client tenterà di connettersi • formula utilizzata per le connessioni in caso di una sessione di registrazione • nel caso del client, l’indirizzo (ip o web) dove il server risiedeSia il programma client che quello server sono stati sviluppati sia per il sistema operativoLinux (dove le modifiche tcp sono state apportate) e Windows 7.3.1 Impatto modifiche apportate allo stackTCPAnalizzare l’impatto dovuto all’utilizzo delle risorse (memoria, cpu, cache ..) di unaconnessione TCP non è un’operazione semplice. Non è un processo sul quale tramite un 33
  35. 35. utility del SO (systat, sysprof) si può applicare un profiling. Proprio per questo motivo lo èancora di più fare un confronto tra i 2 kernel, quello modificato o non.E’ importante però, che le modifiche apportate non introducano alcun ritardo significativosul normale funzionamento dello stack TCP. Quindi è stato istituito un ambiente di testdove l’unica variabile è l’implementazione del kernel onde poter sostenere che l’impattointrodotto dalle modifiche sia accettabile.Ambiente di testUn kernel non modificato ospitato in una VirtualBox, A. Un kernel modificato in unaseconda VirtualBox, B. Su ognuno dei kernel, modificato e non, va in esecuzioneun’istanza dello stesso programma client. Un server C in ascolto sulla porta 80, situatonella stessa macchina dove le macchine virtuali ospitanti i due kernel oggetto di studiovanno in esecuzione.Figura 3.1 Ambiente di test. Macchina A (Vbox): kernel NON modificato; macchina B (Vbox): kernel modificato;macchina C: server in ascolto, in esecuzione sulla macchina ospite (Windows7) 34
  36. 36. Come si può intuire dalla figura, l’unica variabile è il kernel. Il mezzo fisico dicomunicazione tra i client ed il server è lo stesso. Essendo che il mezzo fisico in questocaso è la memoria, esso non introduce alcuna variabile al nostro ambiente.OperazioneNei kernel oggetto di valutazione, vanno in esecuzione simultaneamente i client cheeffettuano dei file upload verso il server in ascolto sulla porta 80. Gli upload vengonoeseguiti in modo sequenziale; la dimensione dei file è fissa, 463917280 bytes; il numero totaledi upload effettuati è 60. Per ogni upload viene tenuta traccia del tempo impiegato. Allafine di questa serie di upload viene trovata una media del tempo impiegato. In conclusioneviene effettuato un confront tra I due kernel, in base alla media di upload. Ci si aspetta chela differenza tra le due medie non sia significativa.RisultatiVengono riportati in seguito i risultati del test di cui sopra. Nel grafico seguente vienetracciata la durata per ogni upload effettuato da ognuno dei client in esecuzione sui kerneloggetto di confronto.Figura 3.2 Confronto in base alla “durata di upload” 35
  37. 37. La tabella seguente riassume la media e la durata complessiva di upload per i due kernel inconfronto. Kernel NON modificato Kernel modificato durata media upload (sec) 155.2 155.56 somma totale durata upload (sec) 9328.07 9334.01Come dai risultati si evince, non vi è alcun ritardo significativo. Mediamente per ambeduei campioni le grandezze, media e somma, sono praticamente uguali.3.2 Impatto sessione di registrazioneUna sessione di registrazione attiva, trascurando per semplicità l’elaborazione dei dati incontesto utente, comporta le seguenti operazioni: • memorizzazione dei valori RTT e RTO nelle opportune strutture dati • esportazione dei dati tra il contesto kernel e quello utenteTali operazioni implicano per prima un consumo di memoria: i buffer creati dove i valoriRTT e RTO verranno memorizzati. Essendo l’esportazione attuata con il memorymapping, la memoria allocata sarà la stessa dall’inizio alla fine della sessione, perciò lapossiamo considerare una costante della nostra funzione impatto. Quindi rimane solamenteil consumo di CPU.Possiamo però, misurare l’impatto di una sessione di registrazione facendo un confrontotra due campioni di connessioni TCP. Il primo campione viene da un kernel modificato esul quale non viene attuata alcuna sessione di registrazione. Il secondo campione vieneugualmente da un kernel modificato sul quale però, una sessione di registrazione vieneattuata. Per entrambi i campioni la formula utilizzata è la stessa. In entrambi i casiverranno effettuati una serie di file upload verso un server. 36
  38. 38. Ambiente di testL’esperimento è simile a quello precedentemente descritto nel paragrafo 3.1. A differenzadi prima, in questo caso in ambedue le macchine virtuali vi è in esecuzione un kernelmodificato. Inoltre, il client in esecuzione sul kernel ospitato nella VirtualBox B attua unasessione di registrazione.OperazioneL’esperimento è stato condotto esattamente come quello precedente, descritto nelparagrafo 3.1.Figura 3.3 Ambiente di test . Macchina A (Vbox): kernel modificato; macchina B (Vbox): kernel modificato sessione diregistrazione in atto; macchina C: server porta 80 in localeRisultatiVengono riportati in seguito i risultati del test di cui sopra. Nel grafico seguente vienetracciata la durata per ogni upload effettuato da ognuno dei client in esecuzione sui kernelin confronto. 37
  39. 39. Figura 3.4 Confronto in base alla “durata di upload”La tabella seguente riassume la media e la durata complessiva di upload per i due kernel inconfronto. Kernel modificato Kernel modificato + sessione rto durata media upload (sec) 155.9 156.04 somma totale durata upload (sec) 9354.31 9356.72Come dai risultati si evince, anche in questo caso non vi è alcun ritardo significativo.Mediamente per ambedue i campioni le grandezze, media e somma, sono praticamenteuguali. 38
  40. 40. 4. CASI DI STUDIOPer rendere meglio l’idea di cosa offre e di come si può utilizzare l’infrastruttura propostasono stati presi in considerazione due casi di studio. Nel primo caso si tratta di una formulagià oggetto di ricerca (vedasi Referenze, [5]): ci si aspetta che i risultati ottenuti sianoallineati con quanto in letteratura riportato. Il secondo caso riguarda una seconda formuladi test, preparata al solo fine di dimostrare la flessibilità dello strumento proposto.L’iter procedurale per ognuno dei casi, è il seguente: • implementare un modulo kernel per l’aggiornamento dinamico di RTO, come la formula oggetto di studio specifica • effettuare, simultaneamente sulla stessa macchina virtuale col kernel modificato, sia utilizzando la formula oggetto di studio che quella standard, una serie di file upload, per ognuno dei quali attuare lato client una sessione di registrazione • effettuare, solamente per il primo caso di studio, simultaneamente sulla stessa macchina virtuale col kernel modificato, sia utilizzando la formula oggetto di studio che quella standard, una serie di file download per ognuno dei quali attuare lato server una sessione di registrazione • confrontare il campione ottenuto con la formula oggetto di studio con quello della standard, in base alle seguenti variabili: o tempo medio di upload/download o tempo totale (per l’intero campione) di upload/download o numero di SYN inviati nella fase 3WHS (solamente per il primo caso di studio) o numero di RTO scaduti successivamente alla fase 3WHS (solamente per il secondo caso di studio) o numero di connessioni outgoing non riuscite o ‘densità di probabilità’ funzione di ‘tempo upload/download’ o ‘distribuzione cumulativa’ funzione di ‘tempo upload/download’ 39
  41. 41. Per tutti gli esperimenti seguenti il numero dei ‘file upload/download’ è 60. La dimensionedel file varia, pertanto sarà specificato per ogni esperimento. Per i file upload è statoimplementato un programma client, il quale attua una sessione di registrazione. Per i filedownload invece, è stato implementato un programma server, il quale attua una sessione diregistrazione. Quindi è importante che, solo dal lato dove la sessione di registrazione vieneattuata vi sia in esecuzione il kernel modificato. Per quanto riguarda la controparte èindifferente: infatto in uno degli scenari seguente la controparte è un sito web.Per quanto riguarda la ‘densità di probabilità’ e la ‘distribuzione cumulativa’ è statoconsiderato il caso della distribuzione normale con media il mediano (Excel - MEDIAN), ecome varianza il quadrato della deviazione standard (Excel - STDDEV).In seguito i termini outgoing e incoming verranno utilizzati per distinguere le connessioniTCP come segue: • outgoing connessione TCP in uscita, risultato di una syscall connect (caso tipico di un client che si collega ad un server) • incoming connessione TCP in ingresso, risultato di una syscall accept (caso tipico di un server che accetta in ingresso una connessione da parte di un client)4.1 Formula ‘chu’In questo caso di studio è stata analizzata la formula per l’aggiornamento dinamico di RTOproposta da H.K. Jerry Chu (vedasi Referenze, [5]). In particolare, l’unica modificaproposta rispetto alla formula standard consiste nel valore iniziale di RTO al momento incui viene iniziato il protocollo di apertura connessione. 40
  42. 42. La formula standard per l’aggiornamento dinamico di RTO è riportata in (rfc2988) edomessa da questo documento per brevità. La formula implementa un algoritmo sviluppatoda Van Jacobson nel 1988 ed utilizzato da allora in tutte le implementazioni di TCP. Ildocumento rfc2988 specifica alcuni dettagli realizzativi necessari per l’applicazione praticadell’algoritmo di Van Jacobson.In particolare, rfc2988 specifica che il valore iniziale per RTO quando non sono disponibilimisure di RTT è 3 s. La formula analizzata in questa sezione invece assume come valoreiniziale per RTO 1 s. Inoltre, a differenza di quella standard, allo scadere del 1° timeout diricezione, il valore di RTO rimane invariato.Osservazioni sulla formula rto oggetto di studioLa motivazione di questa scelta, secondo l’autore, è riassunta nei seguenti punti: • le reti moderni attuali sono più veloci (rispetto al momento in cui il valore iniziale di RTO è stato impostato) • studi (effettuati dallo stesso autore) dimostrano che il valore di RTT nel 97.5% delle connessioni in un test a larga scala è minore di 1 secondo • studi osservano che la percentuale di RTO scaduti nella fase 3WHS (3-way handshake) è intorno al 2% (un valore di certo non trascurabile) • per il 2.5% delle connessioni con un valore di RTT maggiore di 1 secondo, la formula garantisce un rinvio (SYN or SYNACK) sia esso necessario o menoSecondo le osservazioni dell’autore, la formula per l’aggiornamento dinamico di RTOrisulta utile nelle connessione a vita breve, per le quali il tempo di 3WHS è unacomponente non trascurabile. E’ il caso tipico delle pagine html: esse sono composte da uninsieme di risorse tipicamente di piccole dimensioni. La durata di caricamento della paginahtml è il tempo della durata di caricamento massima tra quelle di ognuna delle risorse.Pertanto diminuire la durata della fase 3WHS, nel caso essa sia comparabile con la duratatotale del trasferimento è importante. 41
  43. 43. 4.1.1 Connessioni outgoingPer le connessioni outgoing vengono effettuati una serie di file upload verso un serverTCP - porta 80. Per ogni connessione viene attuata una sessione di registrazione.Scenario 1Figura 4.1 Ambiente di testVengono considerati più di un caso in base all’ubicazione del server, al valore iniziale diRTO (rto_3whs) ed al layer di disturbo (tc) introdotto. Ognuno dei casi comporterà dei testsia con la formula oggetto di studio che quella standard. Infine in base ai risultati ottenuti sicercherà di trarre delle conclusioni.La seguente figura riporta un confronto tra i campioni ottenuti con la formula standard equella oggetto di studio in base alla ‘durata upload’. Il grafico del numero dei ‘syn inviati’necessari per stabilire la connessione viene omesso, in quanto i valori sono uguali a 1, trale due formule, per ogni upload. 42
  44. 44. Figura 4.2 Confronto in base alla “durata di upload”Segue il confronto tra i campioni ottenuti con la formula standard e quella oggetto distudio, in base alla ‘densità di probabilità’ e ‘distribuzione cumulativa’, ambedue funzionedella ‘durata di upload’.Figura 4.3 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa”La tabella seguente riassume la media, la durata complessiva, il numero medio di syninviati ed il numero di connessioni non riuscite per i campioni messi a confronto. standard: rto_3whs = 3000msec chu: rto_3whs = 1000msec durata media upload (sec) 0.55 0.56 somma totale durata upload (sec) 33.17 33.64 43
  45. 45. media syn inviati 1 1 connessioni non riuscite 0 0 dimensione file 99399 99399I risultati non riportano alcuna notevole differenza. Nessun timeout scaduto per unpacchetto SYN e nessuna connessione non riuscita. Il valore iniziale RTO per la formulaoggetto di studio nonostante sia 3 volte più piccolo di quella standard è comunqueabbastanza alto. Infatti in base a registrazioni precedenti, il primo valore registrato RTT(~50 msec) è ampiamente minore di quello iniziale RTO (1000 msec).Scenario 2Lo scenario è identico al precedente tranne che per il valore iniziale di RTO che adifferenza di prima è di 100 msec.La seguente figura riporta il confronto tra i campioni ottenuti con la formula standard equella oggetto di studio in base alla ‘durata di upload’ e del numero dei ‘syn inviati’necessari per stabilire la connessione.Figura 4.4 Confronto in base alla “durata di upload” e “syn inviati” 44
  46. 46. La formula per l’aggiornamento dinamico di RTO oggetto di studio comporta dei rinvii dipacchetti SYN, mentre molto probabilmente l’ACK era in dirittura d’arrivo. Questi rinviipenalizzano anche la stessa durata di upload. Va detto però che il valore iniziale RTO èstato scelto all’incirca il doppio del 1° valore RTT (risultato di precedenti sessioni diregistrazione), come un caso limite appositamente per osservarne gli effetti.Invece la seguente figura riporta un confronto tra i campioni ottenuti con la formulastandard e quella oggetto di studio in base alla ‘densità di probabilità’ e ‘distribuzionecumulativa’, ambedue funzione della ‘durata di upload’.Figura 4.5 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa”Il grafico riguardante la ‘densità di probabilità’ dimostra che il campione proveniente dasessioni con la formula oggetto di studio nonostante abbia una media quasi uguale, è piùsparso rispetto a quello della formula standard. Infatti i valori troppo distanti dalla mediaappartengono appunto a questo campione (tracciato color rosso).La tabella seguente riassume la media, la durata complessiva, il numero medio si syninviati ed il numero di connessioni non riuscite per i campioni messi a confronto. standard: rto_3whs = 3000msec chu: rto_3whs = 100msec 45
  47. 47. durata media upload (sec) 0.55 0.67 somma totale durata upload (sec) 33.4 40.45 media syn inviati 1 1.06 connessioni non riuscite 0 0 dimensione file 99399 99399Scenario 3Figura 4.6 Ambiente di testNello scenario di un server situato nella macchina host e dove sul kernel è stato attivato unlayer di disturbo (tc) i risultati sono diversi in confronti a quelli precedenti. 46
  48. 48. Figura 4.7 Confronto in base alla “durata di upload” e “syn inviati”Si nota anche in questo caso un rinvio di pacchetti SYN più frequente per le connessioniche utilizzano la formula oggetto di studio. A differenza della formula standard però, essoreagisce più velocemente ad eventuali disturbi introdotti dal layer tc.Segue il confronto tra i campioni ottenuti con la formula standard e quella oggetto di studioin base alla ‘densità di probabilità’ e ‘distribuzione cumulativa’, ambedue funzione della‘durata upload’. Anche in questo caso il campione proveniente da sessioni con la formulaoggetto di studio è più sparso. In compenso però la campana è centrata leggermente più asinistra di quella standard, indicando quindi una durata di upload media minore. 47
  49. 49. Figura 4.8 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa”La tabella seguente riassume la media, la durata complessiva, il numero medio si syninviati ed il numero di connessioni non riuscite per i campioni messi a confronto. standard: rto_3whs = 3000msec chu: rto_3whs = 100msec durata media upload (sec) 0.91 0.88 somma totale durata upload (sec) 54.67 53.24 media syn inviati 1 1.26 connessioni non riuscite 4 0 dimensione file 99399 99399Dal confronto tra i due campioni, nello scenario con un layer di disturbo, vanno sottolineatii seguenti punti: • la formula standard necessità 4 connessioni in più rispetto a quella oggetto di studio • la media dei SYN, inviati prima che la connessione sia stabilita, per la formula oggetto di studio è maggiore di quella standard 48
  50. 50. • la media di ‘durata di upload’ per la formula oggetto di studio è minore di quella standard • la ‘durata totale’ dell’intero campione proveniente dalla formula oggetto di studio è minore di quella standard La maggiore durata ‘totale’ e ‘media’ nel caso della formula standard in parte è dovuta anche a: o l’informazione, sull’eventuale 2° pacchetto SYN non ancora confermato, viene recuperata più tardi nel caso della formula standard (ricordiamo che per la formula oggetto di studio, RTO rimane invariata al 1° timeout di ricezione scaduto invece di crescere esponenzialmente come nel caso della formula standard)4.1.2 Connessioni incomingPer le connessioni incoming vengono effettuati una serie di file download da parte di unserver tcp. Vengono eseguiti simultaneamente due applicativi server in una VirtualBoxospitante un kernel modificato. Uno dei server utilizzerà la formula standard, invece l’altroquella oggetto di studio per le connessioni accettate in ingresso. In ambiente Windows (dove laVirtualBox viene ospitata) saranno messi in esecuzione due client che si connetterano ai servereffettuando quindi l’upload di un file di dimensione fissa.Per ogni connessione accettata in ingresso ambedue i server attueranno una sessione diregistrazione. Il motivo della sessione non è tanto per i valori di RTT e RTO (infatti i serversolamente ricevono dati), se non per il numero di RTO scaduti durante la fase iniziale dellaconnessione. Al kernel modificato è stato applicato un layer tc che simula in qualche modo unambiente quanto più simile a quello reale.La figura seguente riporta il confronto tra i campioni ottenuti con la formula standard equella oggetto di studio in base alla ‘durata di download’ ed al numero di ‘synack inviati’necessari per stabilire la connessione. 49
  51. 51. Figura 4.9 Confronto in base alla “durata di download” e “synack inviati”In questo scenario i grafici della ‘durata di download’ sono molto simili nonostante leoscillazioni. Va sottolineato il fatto che il campione proveniente da sessioni con la formulaoggetto di studio ha in media un numero di pacchetti SYNACK inviati maggiore (superiorea 2) rispetto a quella standard.La seguente figura invece, riporta un confronto tra i campioni ottenuti con la formulastandard e quella oggetto di studio in base alla ‘densità di probabilità’ ed alla‘distribuzione cumulativa’ ambedue funzione della ‘durata di upload’. Essa conferma ilfatto che i due campioni sono molto simili sia dal punto di vista della media che dellavarianza. 50
  52. 52. Figura 4.10 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa”La tabella seguente riassume la media, la durata complessiva ed il numero medio si synackinviati per i campioni messi a confronto. In questo scenario non è possibile conoscere ilnumero delle connessioni non riuscite in quanto nel lato server questa informazione mancaovvero le uniche connessioni di cui abbiamo traccia sono quelle accettate. standard: rto_3whs = 3000msec chu: rto_3whs = 100msec durata media download (sec) 4.12 4.05 somma totale durata download (sec) 247.22 243.1 media synack inviati 1.03 2.16 connessioni non riuscite non nota non nota dimensione file 99399 99399Dal confronto tra i due campioni vanno sottolineati i seguenti punti: • la formula oggetto di studio comporta un numero di pacchetti SYNACK inviati maggiore rispetto a quella standard • il tempo impiegato per l’invio del file è più breve nel caso della formula oggetto di studio 51
  53. 53. 4.1.3 Riassunto ed osservazioniLa tabella seguente riporta il riassunto dei risultati, per ogni esperimento effettuato.Figura 4.11 Riassunto risultatiDi primo impatto può sembrare che la formula oggetto di studio sia controproducente, maha pure i suoi punti di forza: • nell’eventualità di un server non presente la connessione viene chiusa prima essendo i tentativi di retry col rinvio del pacchetto SYN limitati, essi verranno esauriti prima rispetto ad un caso con un valore iniziale RTO più alto. Nel caso di un server web questo vorrebbe dire che risorse preziose vengono rilasciate il prima possibile 52
  54. 54. • nell’eventualità di una perdita di pacchetti il loro rinvio è più veloce nel caso i pacchetti vadano persi un rinvio degli stessi avrà luogo prima, con conseguenza un eventuale trasferimento più veloce. D’altra parte però, se i pacchetti non sono persi, ma in dirittura d’arrivo questo implicherebbe della banda occupata inutilmente. Ma se consideriamo il caso di un trasferimento dati di piccole dimensioni (risorse pagine web) l’aumento d’occupazione della banda può essere accettabile in compenso di un tempo di trasferimento più breve • per percorsi specifici il primo valore RTT di una sessione di registrazione può servire come base per il valore iniziale RTO nel caso si volesse modellare l’andamento di RTO per un percorso o per un intervallo giornaliero particolare verso un endpoint specifico, informazioni ottenute da precedenti sessioni di registrazione possono tornare molto utili. Il primo valore RTT registrato da una sessione attuata può servire come un punto di partenza per impostare quello iniziale di RTO. Ovviamente un valore iniziale RTO uguale a quello RTT comporterebbe un rinvio di pacchetti ‘aggressivo’. Invece multipli del valore iniziale di RTT, a partire dal 2, potrebbe dare una migliore prestazione delle connessioni verso quel endpoint.4.2 Formula ‘speedy’Il secondo caso di studio riguarda una formula per l’aggiornamento dinamico di RTO cheutilizza la seguente regola: RTOi = (RTTi * α) + (RTTi-1 * β) + (RTTi-2 * γ) + (RTOi-1 * θ)dove: • i indica il valore corrente, i-1 quello precedente e cosi via • α,β,γ,θ costanti 53
  55. 55. Essa è funzione degli ultimi 3 valori di RTT e dell’ultimo valore di RTO. La componenteRTO è utile particolarmente nel caso in cui non vi è più alcun aggiornamento sui valori diRTT (ovvero nessun ACK in arrivo). In mancanza di questa componente, la RTOrimarrebbe invariata, quando invece è ragionevole che la mancanza di ACK sia una chiaraindicazione che la RTO vada aumentata.La seguente figura fornisce un idea sull’ambiente in cui gli esperimenti sono stati svolti. Adifferenza degli scenari con la formula ‘chu’, in questa sezione saranno consideratisolamente le connessioni outgoing.Figura 4.12 Ambiente di testInoltre, oggetto di confronto tra le due formule saranno gli ‘rto scaduti’ piuttosto che gli‘syn inviati’, in quanto più significativi.L’unica differenza tra i seguenti scenari sarà la formula stessa. Modificandoopportunamente le costanti di cui sopra è possibile avere formule anche molto diverse.Infatti per gli esperimenti seguenti verranno utilizzati valori differenti proprio per 54
  56. 56. evidenziare sia situazioni ‘normali’ che casi limite.4.2.1 Connessioni outgoingScenario 1In questo scenario i valori delle costanti sono: α = 1, β = 0.5, γ = 0.25, θ = 0.5quindi la formula è: RTOi = RTTi + (RTTi-1 / 2) + (RTTi-2 / 4) + (RTOi-1 / 2)La seguente figura riporta il confronto tra i campioni ottenuti con la formula standard equella oggetto di studio in base alla ‘durata di upload’ e dei ‘rto scaduti’.Figura 4.13 Confronto in base alla “durata di upload” e “rto scaduti”Aparte occasionali differenze, in media sia la ‘durata di upload’ che gli ‘rto scaduti’ tra ledue formule sono praticamente uguali. 55
  57. 57. Segue il confronto tra i campioni ottenuti con la formula standard e quella oggetto di studioin base alla ‘densità di probabilità’ e ‘distribuzione cumulativa’, ambedue funzione della‘durata upload’.Figura 4.14 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa”Il grafico della ‘densità di probabilità’ conferma il fatto che ambedue i campioni hannomedia quasi uguale. Infatti le loro campane sono quasi centrate nello stesso punto. Lavarianza del campione della formula oggetto di studio ha un valore minore, motivo per cuiil relativo grafico di ‘densità di probabilità’ è meno schiacciato di quello standard.La tabella seguente riassume la media, la durata complessiva, il numero medio di rtoscaduti ed il numero di connessioni non riuscite. standard: rto_3whs = 3000msec speedy: rto_3whs = 100msec durata media upload (sec) 177.24 174.987 somma totale durata upload (sec) 10634.43 10499.24 media rto scaduti 67.5 71.5 connessioni non riuscite 0 0 dimensione file 1372160 1372160 56
  58. 58. Scenario 2In questo scenario i valori delle costanti sono: α = 1, β = 0.25, γ = 0.125, θ = 0.125quindi la formula è: RTOi = RTTi + (RTTi-1 / 4) + (RTTi-2 / 8) + (RTOi-1 / 8)Rispetto allo scenario precedente i valori RTO calcolati sono in media minori. Questoimplica che il numero di eventuali ritrasmissioni di un pacchetto o insieme di, non ancoraconfermato, sarà maggiore. Si può dire che suddetta formula è ‘aggressiva’ in quantomolto sensibile ad eventuali ritardi nella ‘conferma dell’avvenuta ricezione’.La seguente figura riporta il confronto tra i campioni ottenuti con la formula standard equella oggetto di studio in base alla ‘durata di upload’ e del numero dei ‘rto scaduti’.Figura 4.15 Confronto in base alla “durata di upload” e “rto scaduti”Il grafico di ‘durata di upload’ dimostra in maniera evidente come la formula oggetto distudio effettua il trasferimento dei file in un tempo mediamente minore. Questo risultato 57
  59. 59. arriva a discapito della banda: infatti il numero dei RTO scaduti, quindi delle ritrasmissioniè maggiore rispetto alla formula standard.La seguente figura riporta il confronto tra i campioni ottenuti con la formula standard equella oggetto di studio in base alla ‘densità di probabilità’ e ‘distribuzione cumulativa’,ambedue funzione della ‘durata upload’. In linea con quanto scritto poc’anzi si nota comela campana nel caso della formula oggetto di studio si trova alla sinistra di quella standard.Figura 4.16 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa”La tabella seguente riassume la media, la durata complessiva, il numero medio di rtoscaduti ed il numero di connessioni non riuscite per i campioni messi a confronto. standard: rto_3whs = 3000msec speedy: rto_3whs = 100msec durata media upload (sec) 172.5962 163.1614 somma totale durata upload (sec) 10355.77 9789.681 media rto scaduti 66.85 118.58 connessioni non riuscite 0 0 dimensione file 1372160 1372160 58
  60. 60. Scenario 3In questo scenario i valori delle costanti sono: α = 1, β = 1, γ = 0.5, θ = 0.5quindi la formula è: RTOi = RTTi + RTTi-1 + (RTTi-2 / 2) + (RTOi-1 / 2)Rispetto al 1° scenario, i valori RTO calcolati sono in media maggiori. Questo implica cheil numero di eventuali ritrasmissioni di un pacchetto o insieme di non ancora confermato,sarà minore. Si può dire che suddetta formula è ‘lenta’ in quanto poco sensibile adeventuali ritardi nella ‘conferma dell’avvenuta ricezione’.Figura 4.17 Confronto in base alla “durata di upload” e “rto scaduti”Il grafico della ‘durata upload’ dimostra in maniera evidente come la formula oggetto distudio effettua il trasferimento dei file in un tempo mediamente maggiore. In compensoperò il numero dei RTO scaduti è minore rispetto alla formula standard. Lo scenariocorrente è un altro caso limite, opposto a quello precedente.La seguente figura riporta un confronto tra i campioni ottenuti con la formula standard equella oggetto di studio in base alla ‘densità di probabilità’ e ‘distribuzione cumulativa’, 59

×