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

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 TCP

Relatore Laureando

Chiar.mo Prof. Alberto Bartoli Myrteza Kertusha

Anno Accademico 2011/2012

INDICE

Indice delle figure .............................................................................................................................. 3
Introduzione ....................................................................................................................................... 4
1 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’ ......................................................................... 9
2 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 ........................................................................................................ 28
3 Benchmark .................................................................................................................................... 32
3.1 Impatto modifiche apportate allo stack TCP .......................................................................... 33

1

3.2 Impatto sessione di registrazione ........................................................................................... 36
4 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 ............................................................................................... 61
Conclusioni ....................................................................................................................................... 63
Referenze ......................................................................................................................................... 65
Appendice ........................................................................................................................................ 66

2

INDICE DELLE FIGURE
Figura 2.1 Strutture di supporto alla registrazione RTT e RTO .................................................................................... 12
Figura 2.2 Associazione tra strutture di supporto alla registrazione e quella sock ..................................................... 13
Figura 2.3 Sessione di registrazione RTT e RTO. Buffer i – 2: già elaborato; i – 1: pieno, da elaborare; i + 2:
ancora da riempire ...................................................................................................................................................... 19
Figura 2.4 Associazione tra strutture di supporto all’aggiornamento dinamico di RTO e quella sock ........................ 21
Figura 2.5 Rilascio risorse relative ad una sessione di registrazione (1 di 2) ............................................................... 30
Figura 2.6 Rilascio risorse relative ad una sessione di registrazione (2 di 2) ............................................................... 31

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
Figura 3.2 Confronto in base alla “durata di upload” ................................................................................................. 35
Figura 3.3 Ambiente di test. Macchina A (Vbox): kernel modificato; macchina B (Vbox): kernel modificato
sessione di registrazione in atto; macchina C: server porta 80 in locale ..................................................................... 37
Figura 3.4 Confronto in base alla “durata di upload” ............................................................................................... 388

Figura 4.1 Ambiente di test ......................................................................................................................................... 42
Figura 4.2 Confronto in base alla “durata di upload” ................................................................................................. 43
Figura 4.3 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa” ........................................... 43
Figura 4.4 Confronto in base alla “durata di upload” e “syn inviati” .......................................................................... 44
Figura 4.6 Ambiente di test ......................................................................................................................................... 46
Figura 4.7 Confronto in base alla “durata di upload” e “syn inviati” .......................................................................... 47
Figura 4.9 Confronto in base alla “durata di download” e “synack inviati” ................................................................ 50
Figura 4.10 Confronto in base alla “densità di probabilità” e “distribuzione cumulativa” ......................................... 51
Figura 4.11 Riassunto risultati..................................................................................................................................... 52
Figura 4.12 Ambiente di test ....................................................................................................................................... 54
Figura 4.13 Confronto in base alla “durata di upload” e “rto scaduti” ....................................................................... 55
Figura 4.19 Riassunto risultati..................................................................................................................................... 61

3

INTRODUZIONE
TCP è un protocollo affidabile, che garantisce la trasmissione dei dati tra due endpoint
costituenti la connessione. Tale obiettivo viene raggiunto attuando delle politiche di
ritrasmissione. L’endpoint trasmittente, in mancanza di conferma dell’avvenuta ricezione
dei dati dall’endpoint remoto entro un tempo prestabilito (a causa di ritardi di rete o di
perdita), deve ritrasmettere i dati non ancora confermati. Essi vengono inviati nuovamente
allo scadere di RTO (Retransmission Timeout), grandezza stimata del timeout di
ritrasmissione ed aggiornata dinamicamente anche in base a RTT (Round Trip Time),
grandezza misurata del tempo d'andata e ritorno.

Le formule per l’aggiornamento dinamico di RTO utilizzate nei sistemi operativi odierni
sono quelle che col tempo si sono dimostrate migliori nei contesti più generici. In alcuni
campi particolari, tuttavia, in funzione dell'utilizzo (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 essere
utilizzata in un contesto reale, deve però essere sottoposta ad un processo iterativo di
analisi 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 sistema

Grazie all’infrastruttura oggetto di questa tesi, è possibile modificare la formula per il
calcolo di RTO e testarne immediatamente gli effetti introdotti nella comunicazione, senza
dover far ripartire il sistema operativo, o tanto meno ricompilare il kernel. Volendo
analizzare più in dettaglio suddetti effetti si può accedere ai valori RTT e RTO relativi ad
una connessione TCP.

Il primo capitolo, Architettura, offre una panoramica generale dell’infrastruttura proposta.
Ulteriori dettagli realizzativi seguono nel secondo capitolo, Implementazione. La

4

valuazione dell’impatto dovuto alle modifiche apportate, sulle performance del sistema è
l’argomento del terzo capitolo, Benchmark. Nel quarto capitolo, Casi di studio, vengono
analizzati due casi di studio utilizzando l’infrastruttura proposta.

5

1. ARCHITETTURA
Da 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. Il
secondo sottosistema invece, riguarda la formula per l’aggiornamento dinamico di RTO:
come crearle e/o modificarle, aggiungerle nel sistema ed infine associarle alle connessioni
TCP. Nonostante lo scopo del primo sottosistema è quello di rendere disponibili utili
informazioni al secondo, ognuno dei due può esistere indipendentemente dall’altro.

1.1 Registrazione RTT e RTO

I valori di RTT e RTO vengono calcolati quindi aggiornati nel contesto kernel. Le
condizioni 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


• errore ‘host unreachable’ pervenuto dal modulo icmp


Ogni volta che una delle condizioni di sopra ha luogo, i valori vengono memorizzati nelle
apposite strutture dati in memoria. La memorizzazione riguarda sia RTT che RTO
indipendentemente dalla condizione verificata. Può essere pensata come un’istantanea di
RTT e RTO, il cui scatto avviene a fronte di una delle condizioni di cui sopra. Assieme ai

6

valori di RTT e RTO vengono memorizzati l'istante temporale e il tipo di condizione
verificatasi al fine poter distinguere successivamente nella fase di elaborazione.

Con l'utilizzo di un modulo kernel i valori bufferizzati vengono resi disponibili al contesto
utente. 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 dati
d’interesse è stato implementato un ulteriore layer al fine di semplificare quanto più
possibile il processo da parte dell'operatore. L'unico compito spettante al programmatore è
appunto l'elaborazione stessa dei dati.

1.1.1 Utilizzo

Segue una breve descrizione, di una sequenza d’operazioni da eseguire per accedere ai
valori RTT e RTO relativi ad una connessione.

• apertura device

l'esecuzione 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".
L'inizio 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

“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 driver

La 2° e 3° operazione, ovvero inizio e fine di una sessione di registrazione, possono essere
reiterate 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 sessione
attiva ha l’esclusività sul device: non è possibile attuare una ulteriore se non alla fine di
quella già in corso. Per scelta, è stato preferito la semplicità di utilizzo (apertura di un
ulteriore driver) alla complesità richiesta (demultiplexing, api più complesse).

1.2 Formula aggiornamento dinamico RTO

Il secondo sottosistema riguarda la formula per l’aggiornamento dinamico di RTO. Esso
consente 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 da
quel momento in poi) oppure a scelta, specificatamente ad una connessione.

La formula per il calcolo di RTO utilizzata dal kernel è proposta nella forma di una
funzione. Tale funzione è presente nel codice kernel, quindi apportare modifiche equivale
ad una ricompilazione dello stesso. Purtroppo questa operazione richiede un tempo di
esecuzione non indifferente.

8

Con lo strumento proposto in questa tesi, la formula per l’aggiornamento dinamico di RTO
viene caricata sotto forma di un modulo kernel. In questo modo essa si può modificare
senza dover ricompilare il kernel. Nel kernel vi sono state apportate delle modifiche al fine
di 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 viene
chiamata ogniqualvolta RTO viene aggiornata. La formula attualmente in uso nel kernel è
stata implementata come modulo, caricato automaticamente in fase di boot del sistema.

Utilizzando l'interfaccia ioctl-sockopt è possibile associare una formula a scelta tra quelle
disponibili nel sistema, ad una specifica connessione TCP. Infine utilizzando l'interfaccia
sysfs si può impostare una formula tra quelle disponibili come default.

1.2.1 Utilizzo

L'utilizzo della funzionalità offerta comprende da una parte la possibilità di modificare le
formule e dall'altra quella di associare esse ad una specifica connessione a scelta.

1.2.1.1 Gestione formula per calcolo RTO

La formula viene implementata nella forma di un modulo kernel. La creazione della
formula quindi, equivale all'implementazione del modulo kernel. L'aggiunta e la rimozione
invece equivalgono all’inserimento ed alla rimozione di essa dalla lista dei moduli
disponibili.

Tramite l’interfaccia sysfs del kernel è possibile impostare una delle formule disponibili
come default. Ogni connessione nuova, se non diversamente specificato, utilizzerà la
formula 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 una
connessione è realizzabile tramite l’utilizzo di due diverse interfacce. La prima interfaccia
è quella tipica per la configurazione delle connessioni tcp (setsockopt). Chiamare la suddetta

9

syscall con il nome della formula scelta fa si che da quel istante in poi la, i valori di RTO
vengano calcolati con quella formula. E’ il caso di evidenziare che tale syscall implica che
la connessione TCP sulla quale si vuole intervenire è stata creata dal processo che sta
effettuando la chiamata stessa. Quest’ultimo è dovuto al fatto che il parametro passato in
ingresso 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 valori
di 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 ad
una connessione TCP. In questo modo si ha la possibilità di intervenire anche su una
connessione creata da un altro processo.

10

2. IMPLEMENTAZIONE
In questo capitolo viene fatta una descrizione più dettagliata dell’infrastruttura proposta.
Riallaciandosi all’aspetto funzionale, verrà puntata la lente d’ingrandimento su ognuno dei
due sottosistemi. La loro descrizione riguarderà l’implementazione sia nel contesto kernel
che quello utente. Per poi proseguire con una discussione su varie scelte implementative
fatte.

2.1 Registrazione RTT e RTO

La registrazione dei valori di RTT e RTO avviene sia nel contesto kernel che quello
utente. Nel contesto kernel, l’implementazione segue delle linee guida con un occhio di
riguardo alla prestazione ed alla stabilità. Un possibile errore in questo contesto
renderebbe 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 kernel

L’implementazione nel contesto kernel riguarda una componente “statica”, di supporto per
l’intera infrastruttura. In questa categoria fanno parte tutte le modifiche apportate nella
struttura del kernel che richiedono la sua ricompilazione. Le modifiche apportate alla
struttura 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 la
ricompilazione. Il modulo che si interfaccia con il contesto utente per l’esportazione dei
dati ne fa parte.

11

2.1.1.1 Kernel built2in

Il termine built-in rende meglio l’idea sull’argomento di questo paragrafo. Infatti riguarda
tutte le modifiche integrate nel kernel stesso. Le modifiche fanno da ponte tra il kernel e la
nuova 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

‘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

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

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 kernel

Le funzionalità integrate nel kernel vengono esposte al contesto utente con l’utilizzo dei
moduli kernel. Il loro compito è quello di interfacciarsi da una parte con lo stack TCP e
dall’altra con il contesto utente. Con il contesto utente tale interfacciamento è reso
possibile tramite un device a caratteri: infatti durante la fase di boot del sistema vengono
creati una serie di device, come specificato in /etc/rc.d/rc.modules. Invece dallo stack TCP il
modulo è raggiungibile tramite le api introdotte nella sezione precedente (vedasi
take_sample). Tale modulo viene caricato già nella fase di boot del sistema, come specificato

15

in /etc/rc.d/rc.modules.

Interfaccia con il contesto kernel
Il modulo implementa la funzione take_sample (distinta da quella dello stesso nome
integrata nel kernel) che svolge effettivamente l’operazione di bufferizzazione dei valori
RTT e RTO. L’implementazione volutamente viene fatta nel modulo affinche sia
facilmente modificabile. E’ compito suo bufferizzare i dati opportunamente e soprattutto
notificare il contesto utente in caso si verifichi una condizione particolare (es. buffer
riempito ecc). Quando una sessione di registrazione inizia, uno dei parametri della relativa
struttura è appunto un puntatore di funzione a questa chiamata.

Interfaccia con il contesto utente
L’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 le
linee guida dell’interfaccia ioctl tipica dei device, sono state implementate tutte le
funzionalità richieste. Per quanto riguarda l’esportazione dei dati tra i due contesti esso
viene fatto tramite il memory mapping, ovvero una zona di memoria condivisa tra i due
contesti. In questo modo si risparmia una copia dei dati tra i due contesti. Segue una breve
descrizione 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

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 registrazione

2.1.2 Contesto utente

Il 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 device

Onde 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 utente

La 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

tale struttura è il ‘puntatore di funzione’ che verrà chiamato in presenza di dati da
elaborare. Infatti, il thread creato dallo skeleton, che si occupa di estrarre i dati dal modulo
kernel, chiamerà tale puntatore di funzione per rendere disponibili al programmatore i dati.
Ovviamente l’implementazione di questa funzione spetta al programmatore stesso. Tipici
utilizzi 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 mantenendo
aperto anche lo stesso device. In tutte le api il parametro err_code è di tipo ‘in uscita’ e ha
un 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 si
occupa della formula per l’aggiornamento dinamico di RTO. Le funzionalità offerte sono
facilmente 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 grafica

Il processo che si occupa della registrazione dei valori RTT e RTO viene eseguito sia nel
contesto kernel che quello utente. La generazione degli eventi, il passaggio tra i due
contesti rendono il tutto non facilmente intuibile. Con la seguente descrizione grafica ed i
seguenti commenti sui vari passaggi si cerca appunto di rendere più apprensibile tale
processo.

18

Figura 2.3 Sessione di registrazione RTT e RTO. Buffer i – 2: già elaborato; i – 1: pieno, da elaborare; i + 2: ancora da
riempire

1 L’applicativo nel contesto utente dopo aver aperto il device, selezionato la connessione TCP
d’interesse, effettua una chiamata ioctl bloccante-sincrona con timeout
2 La chiamata ioctl di cui sopra, ritorna al thread chiamante in presenza di dati da elaborare oppure per
timeout. In ambedue i casi l’applicativo ritenta di nuovo la chiamata ioctl (fin tanto che non viene
predisposto altrimenti es. CTRL-C od altro)
3 Nel frattempo eventuali condizioni verificate nello stack TCP (ack ricevuti, timeout scaduti) generano
i valori RTT e RTO che vengono bufferizzati
4 Una volta che uno dei buffer viene riempito lo stesso stack TCP segnala il thread chiamante della
presenza di dati da elaborare
5 A questo punto il thread chiamante a cavallo tra i contesti utente e kernel rientra da quest’ultimo in
quello utente
6 Una volta ritornato al thread chiamante, riconoscendo la presenza nel buffer circolare di dati da
elaborare, 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 questa
fase la prossima chiamata ioctl viene effettuata solo dopo che tutti i dati (anche quelli che eventualmente
arrivano nel frattempo) sono stati elaborati, onde eliminare quanto più possibile i cross-boundaries (le
chiamate ioctl).

19

2.2 Formula RTO

La formula per l’aggiornamento dinamico di RTO è implementata nella forma di un
modulo 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 kernel

Nel contesto kernel l’implementazione riguarda una componente “statica” che consente
l’interfacciarsi tra lo stack TCP ed i moduli kernel tramite i quali le formule stesse sono
implementate. Esso concerne tutte le modifiche apportate nella struttura del kernel che
richiedono la ricompilazione dello stesso. Le modifiche apportate alla struttura sock, i punti
individuati nel kernel dove la formula viene selezionata per la prima volta, dove viene
scelta una diversa formula rispetto a quella di default, dove le chiamate al modulo vengono
fatte ne fanno parte. L’altro componente riguarda la parte “dinamica” le cui modifiche non
necessitano la ricompilazione del kernel. Esso concerne i moduli kernel per le formule.

2.2.1.1 Kernel built2in

Il termine built-in rende meglio l’idea sull’argomento di questo paragrafo. Infatti riguarda
tutte 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

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

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

2.2.1.2 Modulo kernel

I moduli kernel che aggiornano RTO devono implementare delle api con signature ben
definite. Per iniziare, api module_init ed module_exit le quali vengono chiamate
rispettivamente al caricamento ed alla rimozione del modulo stesso. Le seguenti api invece
riguardano l’implementazione della logica per l’aggiornamento dinamico di RTO:

• init
• release
• tcp_calc_synack_rto
• tcp_set_rto
• tcp_set_rtt

La funzione init è chiamata la prima volta che una connessione vuole utilizzare il modulo
in questione. Il modulo incrementa il valore ref_cnt affinche esso non possa essere
rimosso dal sistema mentre in uso. Nel nostro caso nella funzione init vengono inizializzate
variabili della struttura sock con le quali si controllano i valori massimi, minimi ed iniziali
di RTO, attualmente costanti nel kernel. Altre possibili operazioni possono essere
inizializzazioni di eventuale memoria da utilizzare, possibili riferimenti aggiornati ecc.

La funzione release è speculare alla init. Essa è chiamata quando la connessione TCP non
utilizzerà più il modulo in questione. Va evidenziato, che questa chiamata decrementa
anche la variabile ref_cnt del modulo, rendendolo cosi un possibile candidato alla
rimozione. Per questo motivo si deve essere assolutamente sicuri che il modulo non verrà
in alcun modo più utilizzato. Rispettivamente, possibili operazioni sono il rilascio di
eventuale memoria occupata, riferimenti aggiornati ecc.

Una connessione TCP appena creata e prima di essere stabilita si trova in uno dei seguenti
stati 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

• 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 di
supporto, necessitano di una diversa implementazione. Infatti il kernel durante lo stato
TCP_SYN_RECV implementa la logica opportuna con una struttura (request_sock) dati di
supporto più “leggera” dal punto di vista della memoria. Quindi il modulo kernel esporta
due funzioni per il calcolo dinamico di RTO: una per le connessioni (sia incoming che
outgoing) una volta stabilite ed un’altra per le connessioni incoming nella fase
TCP_SYN_RECV ovvero prima che esse siano stabilite.

La funzione tcp_calc_synack_rto viene utilizzata per aggiornare il valore di RTO per una
connessione incoming non ancora stabilita. La connessione TCP entra in questo stato
appena risponde col proprio ACK ad un pacchetto SYN in ingresso. Rimane in questo stato
finche non riceve l’ACK relativo dall’altra estremità, dopo il quale la connessione si sposta
nello stato TCP_ESTABLISHED.

La funzione tcp_set_rto viene utilizzata per aggiornare il valore di RTO per una
connessione TCP in tutti gli altri casi tranne quello precedente.

La funzione tcp_set_rtt viene utilizzata per aggiornare il valore di RTT nella struttura
tcp_sock. Tale funzione è chiamata dallo stack quando un pacchetto o insieme di viene
confermato. In questo modo si ha la possibilità di accedere ai valori RTT nel contesto del
modulo kernel.

2.2.2 Contesto utente

L’interazione tra il contesto utente ed i moduli è riassunta nel loro caricamento e
rimozione. In Linux con l’utilizzo di comandi shell è possibile eseguire tali operazioni:

• caricamento - loading

24

root# insmod nome_formula.ko

• rimozione - unloading

root# rmmod nome_formula

Una volta caricati nel sistema, i moduli sono posti in una lista globale. Tra le formule
disponibili una sarà quella di default, ovvero la formula che ogni connessione TCP
utilizzerà se non diversamente specificato. Tramite l’interfaccia sysfs è possibile avere
informazioni 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_formula

Per impostare una particolare formula ad una specifica connessione vengono utilizzate le
syscall setsockopt/getsockopt. Esse sono delle chiamate simili alle ioctl, ma specifiche alle
socket.

• 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 implementative

La registrazione dei valori RTT e RTO è un processo che merita qualche approfondimento
in più. Esso opera a cavallo tra i due contesti ed inoltre ha un proprio impatto sulle risorse
di memoria e cpu. Quindi vanno indirizzate le seguenti problematiche:

25

• 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 registrazione

2.3.1 Interfaccia tra i due contesti

I valori RTT e RTO memorizzati nel contesto kernel, affinche siano elaborati vanno
esportati 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 della
conoscenza di programmazione, il contesto utente raggiunge una audience più ampia. Tale
processo non è una operazione semplice come ad esempio una copia dei dati da una zona
di 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 programmazione

Per 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

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 utente

La scelta di sopra è dettata nel primo caso dalla semplicità ovvero minimo sforzo possibile
per ottenere le funzionalità richieste: tra i vari possibili device, il più semplice è quello a
caratteri. Nel secondo caso invece la motivazione è la prestazione. Infatti con una diversa
interfaccia (es. copy_to_user, socket etc) si andrebbe incontro ad una copia in più per il
passaggio dei dati tra i due contesti. Il memory mapping invece, espone la zona di memoria
del 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 concorrenziale

Per il passaggio dei dati tra i due contesti (kernel ed utente) viene utilizzata una zona di
memoria condivisa nella forma di un buffer. Essendo esso condiviso tra il produttore (che
aggiunge dati) ed il consumatore (che preleva dati) il problema dell’accesso concorrenziale
va indirizzato. Nel caso in questione si tratta di un unico produttore ed un unico
consumatore il che semplifica di molto la situazione. Questo vorrebbe dire che il momento
in cui la contesa avrà luogo sarà solamente quando ambedue vi accedono al buffer. Nel
caso vi fossero più consumatori e/o produttori oltre alla contesa appena accennata vi
sarebbe anche un’altra che dovrebbe serializzare i multipli produttori e/o consumatori che
siano. L’accesso serializzato al buffer è necessario in quanto nell’aggiornare gli indici
dell’array sia il consumatore che il produttore devono essere sicuri di non interferire col
lavoro dell’altro. Infatti, la prassi in questi casi chiede che l’accesso vada protetto con dei
lock, ovvero il locking a livello kernel col minore overhead.

Il produttore, nel nostro caso lo stack TCP, non si può permettere di aspettare che il
consumatore finisca il suo lavoro. Questo introdurrebbe ritardi, anche minimi che siano, al

27

corso d’azione dello stack TCP. Tali ritardi non solo graverebbero sulla performance del
sistema stesso, sull’andamento della connessione TCP, ma ‘sporcherebbero’ anche i valori
RTT e RTO stessi per i quali l’infrastruttura è stata costruita. Ne consegue che il corso
d’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. Ne
segue 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 verrebbero
sovrascritti con i più nuovi. Ovviamente in tale situazione il produttore sposterebbe anche
l’indice del prossimo dato che il consumatore andrà a consumare e segnalare tale evento
tramite un flag. Sarà compito del consumatore riconoscere dal flag questa situazione e
comportarsi di conseguenza.

Con questa impostazione la contesa tra i due concorrenti non si verifica più: i corsi
d’azione di nessuno dei due viene interrotto in alcun modo dall’altro. Per quanto riguarda il
caso peggiore, ovvero la velocità del produttore maggiore di quella del consumatore,
l’impostazione proposta è sempre preferibile all’interruzione di uno dei due, in attesa della
fine del lavoro dell’altro. Purtroppo non esiste una soluzione al caso peggiore: non esiste
un buffer infinito! Va detto però, che nel nostro caso, la velocità del produttore
difficilmente sarà maggiore di quella del consumatore anche se il sistema stesso fosse sotto
stress: gli eventi oggetti di studio non vengono generati con tale frequenza.

2.3.3 Rilascio delle risorse

La zona di memoria condivisa tra il contesto kernel e quello utente è pursempre una risorsa
di sistema: va comunque liberata dopo il suo utilizzo. Tale zona di memoria è condivisa tra
due processi implicando che il rilascio da parte di uno potrebbe compromettere il corso
d’azione dell’altro. Nel nostro caso uno dei due processi viene ospitato nel contesto kernel
il che peggiora la situazione ulteriormente: un accesso di tipo reference ad una struttura
NULL porterebbe ad un crash del SO intero.

28

Proteggere l’accesso con un lock ha degli svantaggi. Lasciando stare per un attimo il
ritardo introdotto al processo in attesa di rilascio del lock, preoccupa molto di più il blocco
indefinito. Si pensi ad esempio ad un ‘process kill’ a livello utente che già mantiene il lock
sulla struttura. Bloccherebbe indefinitivamente il processo nel contesto kernel in attesa del
rilascio del lock. Anche nel caso in cui la chiusura della connessione TCP possa avere esito
positivo, le risorse (associate appunto alla connessione) non rilasciate, peserebbero a lungo
andare 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 ne
faranno più utilizzo. Ovviamente questo comporta della logica in più, ma consente anche
di 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 si
occuperà 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 come
riferimento in tale lista. In questo modo si ha accesso alla struttura anche quando sia la
connessione che il processo nel contesto utente siano terminati. A quel punto, ovvero
quando la struttura viene segnalata da ambedue i processi come ‘da rilasciare’, il processo
percorrendo la lista e riconoscendola la rimuove, quindi ne rilascia le sue risorse
ritornandole al SO.

Sulla stessa connessione TCP, durante la sua vita, possono avere luogo diverse sessioni di
registrazione. Ognuna di queste sessioni avrà la propria struttura dati. Queste strutture dati
però, andranno rilasciate solamente quando la connessione tcp viene terminata ovvero
quando la struttura sock verrà rilasciata dallo stack tcp stesso. Fintanto che la connessione
TCP è ancora attiva non si può avere la certezza (alla luce anche di possibili future
modifiche del kernel) che nessun accesso verrà fatto dopo che le strutture della sessione
verranno rilasciate.

La lista di cui si accennava poco fa, in realtà è un insieme di due tali. Una legata allo stack
TCP, sock_wrapper_list e l’altra legata alle sessioni di registrazione, session_list. Segue un
esempio ed una descrizione grafica onde descrivere meglio il meccanismo.

29

Con stack = 0 viene indicata una connessione TCP ancora attiva, che alla chiusura diventa
stack = 1. Lo stesso ragionamento vale anche per la variabile module riferita però al
modulo 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, alla
struttura in sock_wrapper_list viene propagata alle rispettive in session_list dal processo
che 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 la
necessità di due liste) proprio per disaccoppiare i corsi d’azione. La prima fase consiste

30

nella segnalazione da parte dello stack TCP di questo evento ponendo la variabile stack del
relativo 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 alle
sessioni. Infatti questo compito viene svolto dal processo di rilascio delle risorse.
Solamente quando anche i moduli segnaleranno di aver preso visione, quindi che non
utilizzeranno 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 strutture
non più utilizzate.

Figura 2. 6 Rilascio risorse relative ad una sessione di registrazione (2 di 2)

31

3. BENCHMARK
Le modifiche apportate nel kernel implicano indubbiamente un impatto sulla performance
del sistema. Alla struttura sock sono state aggiunte dei riferimenti a quella di supporto
all’infrastruttura proposta. La struttura riferita riguarda sia l’aspetto ‘registrazione di RTT
e RTO’ che ‘formula per l’aggiornamento dinamico di RTO’. Anche il processo che in
background si occupa di rilasciare le risorse non più utilizzate, ha la propria componente di
impatto sulla performance.

Quanto accennato riguarda il sistema nel suo intero indipendentemente dal fatto se una
registrazione è attiva o meno. Qualora lo fosse, alle variabili che influiscono sulla
performance vanno aggiunte delle ulteriori. La struttura dati inizializzata per il passaggio
dei dati tra il livello kernel ed utente. Inoltre il thread a livello utente che si occupa appunto
di esportare i dati dal contesto kernel, implica ulteriori risorse utlizzate sia di memoria che
cpu.

Ai fini di un’analisi più semplificata, suddivideremo il problema in due. Il primo
riguarderà solamente le modifiche apportate al kernel, lasciando fuori dall’equazione la
sessione di registrazione. Verranno messi a confronto un kernel modificato ed uno non. Il
secondo riguarderà solamente la sessione di registrazione. Verranno messi a confronto due
kernel modificati, su uno dei quali però una sessione di registrazione è attiva.

Modifiche apportate allo stack TCP
Le seguenti operazioni verranno effettuate ogniqualvolta una delle condizioni di
aggiornamento di RTO ha luogo:

• accesso al modulo per aggiornare il valore di RTO
• controllo se una sessione di registrazione è attiva

Nel caso la seconda operazione avesse esito positivo, altre, riguardanti la parte che si
occupa della registrazione dei valori RTT e RTO, ne seguirebbero. Esse non vengono prese
in considerazione ai fini dell’analisi in quanto hanno un impatto attribuibile allo stack TCP

32

solamente quando una sessione di registrazione è in atto. Ambedue le operazioni hanno un
numero ben definito di istruzioni, non soggetto di alcun ritardo dovuto ad altri processi
quindi deterministiche.

Sessione di registrazione attiva
Nel caso di una sessione di registrazione saranno prese in considerazione le seguenti
operazioni:

• memorizzazione dei valori RTT e RTO nelle opportune strutture dati
• esportazione dei dati tra il contesto kernel e quello utente

In questo caso abbiamo trascurato di proposito l’operazione effettuata dall’applicativo sui
dati esportati. Possiamo considerare il caso in cui i dati ottenuti vengono semplicemente
scartati (es. instradati in /dev/null) onde semplificare l’analisi.

Per effettuare gli esperimenti sono stati costruiti due programmi di test. Un programma che
svolgerà il ruolo del client ed un altro quello del server. Ambedue i programmi tramite i
parametri 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 risiede

Sia il programma client che quello server sono stati sviluppati sia per il sistema operativo
Linux (dove le modifiche tcp sono state apportate) e Windows 7.

3.1 Impatto modifiche apportate allo stack

TCP

Analizzare l’impatto dovuto all’utilizzo delle risorse (memoria, cpu, cache ..) di una
connessione TCP non è un’operazione semplice. Non è un processo sul quale tramite un

33

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 significativo
sul normale funzionamento dello stack TCP. Quindi è stato istituito un ambiente di test
dove l’unica variabile è l’implementazione del kernel onde poter sostenere che l’impatto
introdotto dalle modifiche sia accettabile.

Ambiente di test
Un kernel non modificato ospitato in una VirtualBox, A. Un kernel modificato in una
seconda VirtualBox, B. Su ognuno dei kernel, modificato e non, va in esecuzione
un’istanza dello stesso programma client. Un server C in ascolto sulla porta 80, situato
nella stessa macchina dove le macchine virtuali ospitanti i due kernel oggetto di studio
vanno 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

Come si può intuire dalla figura, l’unica variabile è il kernel. Il mezzo fisico di
comunicazione tra i client ed il server è lo stesso. Essendo che il mezzo fisico in questo
caso è la memoria, esso non introduce alcuna variabile al nostro ambiente.

Operazione
Nei kernel oggetto di valutazione, vanno in esecuzione simultaneamente i client che
effettuano dei file upload verso il server in ascolto sulla porta 80. Gli upload vengono
eseguiti in modo sequenziale; la dimensione dei file è fissa, 463917280 bytes; il numero totale
di upload effettuati è 60. Per ogni upload viene tenuta traccia del tempo impiegato. Alla
fine di questa serie di upload viene trovata una media del tempo impiegato. In conclusione
viene effettuato un confront tra I due kernel, in base alla media di upload. Ci si aspetta che
la differenza tra le due medie non sia significativa.

Risultati
Vengono riportati in seguito i risultati del test di cui sopra. Nel grafico seguente viene
tracciata la durata per ogni upload effettuato da ognuno dei client in esecuzione sui kernel
oggetto di confronto.

Figura 3.2 Confronto in base alla “durata di upload”

35

La tabella seguente riassume la media e la durata complessiva di upload per i due kernel in
confronto.

Kernel NON modificato Kernel modificato

durata media upload (sec) 155.2 155.56

somma totale durata upload (sec) 9328.07 9334.01

Come dai risultati si evince, non vi è alcun ritardo significativo. Mediamente per ambedue
i campioni le grandezze, media e somma, sono praticamente uguali.

3.2 Impatto sessione di registrazione

Una sessione di registrazione attiva, trascurando per semplicità l’elaborazione dei dati in
contesto utente, comporta le seguenti operazioni:

• memorizzazione dei valori RTT e RTO nelle opportune strutture dati
• esportazione dei dati tra il contesto kernel e quello utente

Tali operazioni implicano per prima un consumo di memoria: i buffer creati dove i valori
RTT e RTO verranno memorizzati. Essendo l’esportazione attuata con il memory
mapping, la memoria allocata sarà la stessa dall’inizio alla fine della sessione, perciò la
possiamo considerare una costante della nostra funzione impatto. Quindi rimane solamente
il consumo di CPU.

Possiamo però, misurare l’impatto di una sessione di registrazione facendo un confronto
tra due campioni di connessioni TCP. Il primo campione viene da un kernel modificato e
sul quale non viene attuata alcuna sessione di registrazione. Il secondo campione viene
ugualmente da un kernel modificato sul quale però, una sessione di registrazione viene
attuata. Per entrambi i campioni la formula utilizzata è la stessa. In entrambi i casi
verranno effettuati una serie di file upload verso un server.

36

Ambiente di test
L’esperimento è simile a quello precedentemente descritto nel paragrafo 3.1. A differenza
di prima, in questo caso in ambedue le macchine virtuali vi è in esecuzione un kernel
modificato. Inoltre, il client in esecuzione sul kernel ospitato nella VirtualBox B attua una
sessione di registrazione.

Operazione
L’esperimento è stato condotto esattamente come quello precedente, descritto nel
paragrafo 3.1.

Figura 3.3 Ambiente di test . Macchina A (Vbox): kernel modificato; macchina B (Vbox): kernel modificato sessione di
registrazione in atto; macchina C: server porta 80 in locale

Risultati
Vengono riportati in seguito i risultati del test di cui sopra. Nel grafico seguente viene
tracciata la durata per ogni upload effettuato da ognuno dei client in esecuzione sui kernel
in confronto.

37


La tabella seguente riassume la media e la durata complessiva di upload per i due kernel in
confronto.

Kernel modificato Kernel modificato + sessione rto



Come dai risultati si evince, anche in questo caso non vi è alcun ritardo significativo.
Mediamente per ambedue i campioni le grandezze, media e somma, sono praticamente
uguali.

38

4. CASI DI STUDIO
Per rendere meglio l’idea di cosa offre e di come si può utilizzare l’infrastruttura proposta
sono stati presi in considerazione due casi di studio. Nel primo caso si tratta di una formula
già oggetto di ricerca (vedasi Referenze, [5]): ci si aspetta che i risultati ottenuti siano
allineati con quanto in letteratura riportato. Il secondo caso riguarda una seconda formula
di 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

Per tutti gli esperimenti seguenti il numero dei ‘file upload/download’ è 60. La dimensione
del file varia, pertanto sarà specificato per ogni esperimento. Per i file upload è stato
implementato un programma client, il quale attua una sessione di registrazione. Per i file
download invece, è stato implementato un programma server, il quale attua una sessione di
registrazione. Quindi è importante che, solo dal lato dove la sessione di registrazione viene
attuata 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’ è stato
considerato il caso della distribuzione normale con media il mediano (Excel - MEDIAN), e
come varianza il quadrato della deviazione standard (Excel - STDDEV).

In seguito i termini outgoing e incoming verranno utilizzati per distinguere le connessioni
TCP 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 RTO
proposta da H.K. Jerry Chu (vedasi Referenze, [5]). In particolare, l’unica modifica
proposta rispetto alla formula standard consiste nel valore iniziale di RTO al momento in
cui viene iniziato il protocollo di apertura connessione.

40

La formula standard per l’aggiornamento dinamico di RTO è riportata in (rfc2988) ed
omessa da questo documento per brevità. La formula implementa un algoritmo sviluppato
da Van Jacobson nel 1988 ed utilizzato da allora in tutte le implementazioni di TCP. Il
documento rfc2988 specifica alcuni dettagli realizzativi necessari per l’applicazione pratica
dell’algoritmo di Van Jacobson.

In particolare, rfc2988 specifica che il valore iniziale per RTO quando non sono disponibili
misure di RTT è 3 s. La formula analizzata in questa sezione invece assume come valore
iniziale per RTO 1 s. Inoltre, a differenza di quella standard, allo scadere del 1° timeout di
ricezione, il valore di RTO rimane invariato.

Osservazioni sulla formula rto oggetto di studio
La 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 meno

Secondo le osservazioni dell’autore, la formula per l’aggiornamento dinamico di RTO
risulta utile nelle connessione a vita breve, per le quali il tempo di 3WHS è una
componente non trascurabile. E’ il caso tipico delle pagine html: esse sono composte da un
insieme di risorse tipicamente di piccole dimensioni. La durata di caricamento della pagina
html è 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 durata
totale del trasferimento è importante.

41

4.1.1 Connessioni outgoing

Per le connessioni outgoing vengono effettuati una serie di file upload verso un server
TCP - porta 80. Per ogni connessione viene attuata una sessione di registrazione.

Scenario 1

Figura 4.1 Ambiente di test

Vengono considerati più di un caso in base all’ubicazione del server, al valore iniziale di
RTO (rto_3whs) ed al layer di disturbo (tc) introdotto. Ognuno dei casi comporterà dei test
sia con la formula oggetto di studio che quella standard. Infine in base ai risultati ottenuti si
cercherà di trarre delle conclusioni.

La seguente figura riporta un confronto tra i campioni ottenuti con la formula standard e
quella 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, tra
le due formule, per ogni upload.

42


Segue il confronto tra i campioni ottenuti con la formula standard e quella oggetto di
studio, in base alla ‘densità di probabilità’ e ‘distribuzione cumulativa’, ambedue funzione
della ‘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 syn
inviati ed il numero di connessioni non riuscite per i campioni messi a confronto.

standard: rto_3whs = 3000msec chu: rto_3whs = 1000msec



43

media syn inviati 1 1

connessioni non riuscite 0 0

dimensione file 99399 99399

I risultati non riportano alcuna notevole differenza. Nessun timeout scaduto per un
pacchetto SYN e nessuna connessione non riuscita. Il valore iniziale RTO per la formula
oggetto di studio nonostante sia 3 volte più piccolo di quella standard è comunque
abbastanza alto. Infatti in base a registrazioni precedenti, il primo valore registrato RTT
(~50 msec) è ampiamente minore di quello iniziale RTO (1000 msec).

Scenario 2
Lo scenario è identico al precedente tranne che per il valore iniziale di RTO che a
differenza di prima è di 100 msec.

La seguente figura riporta il confronto tra i campioni ottenuti con la formula standard e
quella 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

La formula per l’aggiornamento dinamico di RTO oggetto di studio comporta dei rinvii di
pacchetti SYN, mentre molto probabilmente l’ACK era in dirittura d’arrivo. Questi rinvii
penalizzano 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 di
registrazione), come un caso limite appositamente per osservarne gli effetti.

Invece la seguente figura riporta un confronto tra i campioni ottenuti con la formula
standard e quella oggetto di studio in base alla ‘densità di probabilità’ e ‘distribuzione
cumulativa’, ambedue funzione della ‘durata di upload’.


Il grafico riguardante la ‘densità di probabilità’ dimostra che il campione proveniente da
sessioni 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 media
appartengono appunto a questo campione (tracciato color rosso).

La tabella seguente riassume la media, la durata complessiva, il numero medio si syn


45



media syn inviati 1 1.06



Scenario 3


Nello scenario di un server situato nella macchina host e dove sul kernel è stato attivato un
layer di disturbo (tc) i risultati sono diversi in confronti a quelli precedenti.

46

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 connessioni
che utilizzano la formula oggetto di studio. A differenza della formula standard però, esso
reagisce più velocemente ad eventuali disturbi introdotti dal layer tc.

Segue il confronto tra i campioni ottenuti con la formula standard e quella oggetto di studio
in base alla ‘densità di probabilità’ e ‘distribuzione cumulativa’, ambedue funzione della
‘durata upload’. Anche in questo caso il campione proveniente da sessioni con la formula
oggetto di studio è più sparso. In compenso però la campana è centrata leggermente più a
sinistra di quella standard, indicando quindi una durata di upload media minore.

47


La tabella seguente riassume la media, la durata complessiva, il numero medio si syn




media syn inviati 1 1.26



Dal confronto tra i due campioni, nello scenario con un layer di disturbo, vanno sottolineati
i 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

• 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 incoming

Per le connessioni incoming vengono effettuati una serie di file download da parte di un
server tcp. Vengono eseguiti simultaneamente due applicativi server in una VirtualBox
ospitante un kernel modificato. Uno dei server utilizzerà la formula standard, invece l’altro
quella oggetto di studio per le connessioni accettate in ingresso. In ambiente Windows (dove la
VirtualBox viene ospitata) saranno messi in esecuzione due client che si connetterano ai server
effettuando quindi l’upload di un file di dimensione fissa.

Per ogni connessione accettata in ingresso ambedue i server attueranno una sessione di
registrazione. Il motivo della sessione non è tanto per i valori di RTT e RTO (infatti i server
solamente ricevono dati), se non per il numero di RTO scaduti durante la fase iniziale della
connessione. Al kernel modificato è stato applicato un layer tc che simula in qualche modo un
ambiente quanto più simile a quello reale.

La figura seguente riporta il confronto tra i campioni ottenuti con la formula standard e
quella oggetto di studio in base alla ‘durata di download’ ed al numero di ‘synack inviati’
necessari per stabilire la connessione.

49

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 le
oscillazioni. Va sottolineato il fatto che il campione proveniente da sessioni con la formula
oggetto di studio ha in media un numero di pacchetti SYNACK inviati maggiore (superiore
a 2) rispetto a quella standard.

La seguente figura invece, riporta un confronto tra i campioni ottenuti con la formula
standard e quella oggetto di studio in base alla ‘densità di probabilità’ ed alla
‘distribuzione cumulativa’ ambedue funzione della ‘durata di upload’. Essa conferma il
fatto che i due campioni sono molto simili sia dal punto di vista della media che della
varianza.

50


La tabella seguente riassume la media, la durata complessiva ed il numero medio si synack
inviati per i campioni messi a confronto. In questo scenario non è possibile conoscere il
numero delle connessioni non riuscite in quanto nel lato server questa informazione manca
ovvero le uniche connessioni di cui abbiamo traccia sono quelle accettate.


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


Dal 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

4.1.3 Riassunto ed osservazioni

La tabella seguente riporta il riassunto dei risultati, per ogni esperimento effettuato.

Figura 4.11 Riassunto risultati

Di primo impatto può sembrare che la formula oggetto di studio sia controproducente, ma
ha 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

• 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 che
utilizza 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

Essa è funzione degli ultimi 3 valori di RTT e dell’ultimo valore di RTO. La componente
RTO è utile particolarmente nel caso in cui non vi è più alcun aggiornamento sui valori di
RTT (ovvero nessun ACK in arrivo). In mancanza di questa componente, la RTO
rimarrebbe invariata, quando invece è ragionevole che la mancanza di ACK sia una chiara
indicazione che la RTO vada aumentata.

La seguente figura fornisce un idea sull’ambiente in cui gli esperimenti sono stati svolti. A
differenza degli scenari con la formula ‘chu’, in questa sezione saranno considerati
solamente le connessioni outgoing.


Inoltre, 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. Modificando
opportunamente le costanti di cui sopra è possibile avere formule anche molto diverse.
Infatti per gli esperimenti seguenti verranno utilizzati valori differenti proprio per

54

evidenziare sia situazioni ‘normali’ che casi limite.

4.2.1 Connessioni outgoing

Scenario 1
In questo scenario i valori delle costanti sono:

α = 1, β = 0.5, γ = 0.25, θ = 0.5

quindi la formula è:

RTOi = RTTi + (RTTi-1 / 2) + (RTTi-2 / 4) + (RTOi-1 / 2)

quella 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 le
due formule sono praticamente uguali.

55

Segue il confronto tra i campioni ottenuti con la formula standard e quella oggetto di studio
in base alla ‘densità di probabilità’ e ‘distribuzione cumulativa’, ambedue funzione della
‘durata upload’.


Il grafico della ‘densità di probabilità’ conferma il fatto che ambedue i campioni hanno
media quasi uguale. Infatti le loro campane sono quasi centrate nello stesso punto. La
varianza del campione della formula oggetto di studio ha un valore minore, motivo per cui
il relativo grafico di ‘densità di probabilità’ è meno schiacciato di quello standard.

La tabella seguente riassume la media, la durata complessiva, il numero medio di rto
scaduti ed il numero di connessioni non riuscite.

standard: rto_3whs = 3000msec speedy: rto_3whs = 100msec



media rto scaduti 67.5 71.5



56

Scenario 2

α = 1, β = 0.25, γ = 0.125, θ = 0.125


RTOi = RTTi + (RTTi-1 / 4) + (RTTi-2 / 8) + (RTOi-1 / 8)

Rispetto allo scenario precedente i valori RTO calcolati sono in media minori. Questo
implica che il numero di eventuali ritrasmissioni di un pacchetto o insieme di, non ancora
confermato, sarà maggiore. Si può dire che suddetta formula è ‘aggressiva’ in quanto
molto sensibile ad eventuali ritardi nella ‘conferma dell’avvenuta ricezione’.

quella oggetto di studio in base alla ‘durata di upload’ e del numero dei ‘rto scaduti’.


Il grafico di ‘durata di upload’ dimostra in maniera evidente come la formula oggetto di
studio effettua il trasferimento dei file in un tempo mediamente minore. Questo risultato

57

arriva a discapito della banda: infatti il numero dei RTO scaduti, quindi delle ritrasmissioni
è maggiore rispetto alla formula standard.

quella 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 come
la campana nel caso della formula oggetto di studio si trova alla sinistra di quella standard.


scaduti ed il numero di connessioni non riuscite per i campioni messi a confronto.




media rto scaduti 66.85 118.58



58

Scenario 3

α = 1, β = 1, γ = 0.5, θ = 0.5


RTOi = RTTi + RTTi-1 + (RTTi-2 / 2) + (RTOi-1 / 2)

Rispetto al 1° scenario, i valori RTO calcolati sono in media maggiori. Questo implica che
il 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 ad
eventuali ritardi nella ‘conferma dell’avvenuta ricezione’.


Il grafico della ‘durata upload’ dimostra in maniera evidente come la formula oggetto di
studio effettua il trasferimento dei file in un tempo mediamente maggiore. In compenso
però il numero dei RTO scaduti è minore rispetto alla formula standard. Lo scenario
corrente è un altro caso limite, opposto a quello precedente.

La seguente figura riporta un confronto tra i campioni ottenuti con la formula standard e
quella oggetto di studio in base alla ‘densità di probabilità’ e ‘distribuzione cumulativa’,

59

ambedue funzione della ‘durata upload’. In linea con quanto scritto poc’anzi si nota come
la campana nel caso della formula oggetto di studio si trova alla destra di quella standard.


scaduti ed il numero di connessioni non riuscite per i campioni messi a confronto.




media syn inviati 70.86 52.08



60

4.2.2 Riassunto ed osservazioni
La tabella seguente riporta un riassunto dei risultati di ciascuno degli esperimenti effettuati.

Figura 4.19 Riassunto risultati

Come evidenziato in precedenza il motivo degli esperimenti di questa sezione è solamente
quello di utilizzare lo strumento proposto. Utilizzando una formula per il calcolo dinamico
RTO, funzione dei valori precedenti di RTT e RTO, opportunamente pesati, si è visto che
si possono ottenere diversi risultati. In particolare:

• utilizzando una formula ‘aggressiva’, in media i trasferimenti sono di durata
minore rispetto alla formula standard. Ovviamente a discapito della banda: un
numero maggiore di rto scaduti implica un numero maggiore di ritrasmissioni

61

• utilizzando una formula ‘lenta’, in media i trasferimenti sono di durata maggiore
rispetto alla formula standard. In compenso però si ha un occhio di riguardo alla
banda
• utilizzando una formula ‘equilibrata’, ovvero i cui valori RTO sono compresi tra il
minimo ed il massimo dei due scenari precedenti, in media i trasferimenti sono
simili alla formula standard

62

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (9)

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

Ähnlich wie Progetto e realizzazione di un kernel linux per il controllo dinamico degli stimatori di perdita in tcp (20)

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