In più di una occasione ci è capitato di descrivere gli obiettivi della nostra sperimentazione e della nostra rete; in realtà finora non abbiamo mai quantizzato e puntualizzato alcun criterio o parametro che potesse fornire dei numeri, ovvero delle “metriche” , atte a valutare quantitativamente come la nostra rete si sta comportando, come pure a valutare come eventuali interventi sulla rete possano portare o meno a dei miglioramenti.

Fin dall’inizio ci siamo posti il problema di raccogliere e conservare dei dati storici di alcuni parametri tecnici che potessero fornire elementi di valutazione delle performancies della nostra rete.

In particolare tutti sapete che fin dall’inizio abbiamo creato un server in grado di stimolare la rete e raccogliere una serie di dati conservandoli in modo da avere una storia della rete.

I parametri che abbiamo raccolto sono in parte ottenuti dai singoli nodi come parte integrante del funzionamento dei nodi stessi, ad es. i valori delle intensità dei segnali ricevuti, i valori della velocità di trasmissione e ricezione, etc., in parte ottenuti come risultati di test effettuati dal server stesso verso i singoli nodi della rete, quali ad es. i valori del ping e del packet loss.

Come conseguenza di queste modalità di raccolta dei dati di funzionamento, alcuni dati si riferiscono a singoli link tra nodi, in parte si riferiscono invece a collegamenti end-to-end tra i singoli nodi e il server deputato a raccogliere le statistiche.

L’insieme dei dati raccolti è liberamente accessibile in forma diagrammata tramite il sito http://meshtest.sarimesh.net dove è possibile consultare per ogni singolo nodo tutti i dati raccolti, storicizzati in modo da vedere a colpo d’occhio sia il dettaglio, per i periodi più recenti, che gli andamenti, per i periodi più lunghi.

Gli stessi dati sono tenuti e conservati in forma grezza anche sul server delle statistiche e possono all’occorrenza essere utilizzati per calcolare eventuali altri parametri, anche se inizialmente non previsti.

I dati descritti sono ovviamente una mole notevole, e sono difficilmente utilizzabili in maniera semplice per dare una idea di come la rete stia funzionando o meglio di come la rete stia facendo il suo compito.

A questo punto della sperimentazione appare quindi interessante cercare di vedere se si possano creare dei parametri più sintetici per ottenere questo obbiettivo.

Ovviamente la prima domanda a cui bisogna rispondere è: cosa significa “come la rete stia facendo il suo compito”  ?

Capirete bene che bisogna innanzitutto chiarirci le idee su quale sia il compito della nostra rete.….  e qui il discorso diventa piuttosto filosofico….

Come spero tutti sapete la rete SARIMESH nasce come una rete di collegamento tra radioamatori con una vocazione verso le tematiche di emergenza e di superamento del “digital divide” inteso come possibilità di connettere al mondo zone o persone non altrimenti connesse.

Quindi volendo argomentare sul tema, l’obiettivo NON è quello di sostenere significative moli di traffico, ma piuttosto consentire di “fare del traffico”.…  per intenderci è importante riuscire a realizzare un collegamento a 10 Mbit/sec tra due punti, ma non necessariamente fare traffico a 10Mbit/sec tra tutti i nodi della rete simultaneamente ….

Quindi più che interessarci le “quantità” di traffico, ci interessa la possibilità e la qualità del traffico.... per fare un esempio forse più comprensibile quello che interessa non è l’essere in grado di “scaricare” dei files tramite FTP da un sito, quanto piuttosto essere in grado di navigare velocemente su su sito internet, o essere in grado di interagire con degli applicativi client/server con dei tempi di risposta accettabili…..

Il parametro forse più importante è in realtà la semplice possibilità di stabilire una connessione stabile tra due punti sulla rete; cosa si intenda per “connessione stabile” dipende ovviamente dal tipo di connessione:  diverso è riferirsi ad una connessione vocale trasportata su IP, oppure ad una connessione verso una webcam sempre collegata tramite IP, oppure ad una connessione alla console di un computer remotato tramite la rete IP….

Un altro discorso importante da introdurre è quello della “disponibilità”; questo termine viene definito matematicamente come la percentuale del tempo durante il quale  un certo sistema svolga correttamente il suo ruolo: nel nostro caso potremmo quindi parlare di disponibilità per tutta una serie di aspetti….

Per esempio potremmo considerare l’aspetto della “connettività” tra una copia di nodi, oppure tra un nodo generico ed un nodo di riferimento, oppure inventarci altri aspetti da valutare…  è evidente che ogni scelta avrebbe i suoi significati, i suoi pregi e i suoi difetti…

Se consideriamo gli obiettivi che la nostra rete si prefigge, potremmo dire che forse il principale aspetto che ci potrebbe interessare è proprio quello della connettività tra i singoli nodi ed un nodo predefinito;  un tale modello ben si cala su uno scenario di tipo emergenziale in cui verosimilmente si voglia collegare dei punti periferici ad un centro di coordinamento…

Inoltre data la struttura e la modalità operativa della rete MESH, più che interessare il comportamento di un singolo link tra nodi, quello che interessa è la possibilità di raggiungere un qualsiasi nodo anche attraversando nodi intermedi non meglio precisati….

Ovviamente nulla toglie che si possano anche considerare un mix di situazioni, ove questo abbia un senso; un esempio potrebbe essere quello dei link tra nodi chiave della rete (Backbone) che di per se stessi possono rappresentare dei punti di criticità della rete.

Considerando quindi gli aspetti di cui sopra e sulla base dei dati che stiamo raccogliendo una possibile idea di definizione di una metrica di disponibilità potrebbe essere quella di considerare l’utilizzabilità di un link sulla base dei seguenti criteri:

• valori del tempo di ping ( andata e ritorno) inferiore ad una certa soglia ad es. 50 msec
• valori del parametro packet loss ( ovvero perdita di pacchetti) inferiore ad una certa soglia ad es. 5%

 

Questi due parametri e le relative soglie proposte, non sono casuali: infatti sono  due dei parametri base che si usano nel campo della tecnologia VoIP (Voice Over IP) per valutare l’utilizzabilità di una connessione IP per realizzare un collegamento vocale di qualità accettabile; per inciso il terzo parametro che in genere si usa è il cosiddetto jitter che nella nostra rete noi attualmente non acquisiamo.

Se un link IP presenta valori accettabili per la metrica indicata, è possibile ritenere che siano egualmente accettabili la maggior parte dei servizi che possono usare la connettività IP, a parte quelli tipicamente “pesanti” quali ad es. trasferimento di files.

Come conclusione di questa lunga chiacchierata potremmo quindi dire che un obiettivo da porci potrebbe essere a questo punto quello di provare a mettere su un sistema di calcolo di questo parametro sfruttando i dati acquisiti dal nostro server sariserver in modo da arricchire la tabella delle statistiche anche con dei dati di disponibilità a breve, medio e lungo termine, intendendo con tali termini rispettivamente l’ultima giornata, l’ultima settimana e gli ultimi mesi.

I valori di questi parametri potranno a loro volta essere conservati e storicizzati in modo da fornire una indicazione dello stato di disponibilità della rete nel suo complesso.