Un prototipo per misurare l’instabilità

Non sempre la strada più ampia è la più veloce per arrivare a destinazione. Ce lo dice l’esperienza: a volte sono le strade meno spaziose, ma con un traffico più fluido, a farci arrivare prima. Nella rete accade qualcosa di simile: i pacchetti di dati vengono instradati secondo delle priorità definite nei protocolli di routing che, in genere, privilegiano i percorsi con maggiore capacità, ossia le strade a maggior banda disponibile. Questa scelta, adatta per le applicazioni che richiedono molta banda (capacitive) non è sempre la migliore per quelle in tempo reale, dove un ritardo (latenza) o un’instabilità (jitter) comportano degli effetti deleteri sul servizio. Ma come stabilire quali sono i percorsi più adatti alle applicazioni in real-time? Purtroppo i meccanismi di monitoraggio normalmente in uso non forniscono uno storico dell’andamento e la localizzazione dei parametri di latenza e jitter, essendo più focalizzati a misurare le variazioni di banda disponibile. Serve quindi qualcosa che mappi le instabilità all’interno della rete, per poter prendere delle decisioni informate a riguardo. Un prototipo di questo strumento oggi c’è, si chiama Timemap e ce lo raccontano i nostri Fabio Farina e Claudio Allocchio che lo hanno ideato insieme al gruppo Network Technologies & Services Development del progetto GN4-3.

Cos’è Timemap?

Allocchio: Timemap è un servizio di network monitoring che integra quelli esistenti raccogliendo e visualizzando l’andamento nel tempo dei dati di latenza e jitter su una rete. Al momento è pensato per essere attivo su tutto il backbone GÉANT, ma anche per le reti della ricerca (NREN) europee che lo vorranno installare. Gli utenti del servizio sono principalmente i NOC, a partire da quello di GÉANT.
Timemap è una weathermap evoluta, cioè uno strumento di visualizzazione dei dati di monitoraggio sotto forma di mappa che mostra le informazioni sulla rete segmento per segmento; ma stiamo anche integrando la visualizzazione da alcuni punti verso tutti i PoP del backbone, per esempio da Berlino a Madrid. È uno strumento di supporto al debugging, nel momento in cui si cerca di risolvere un rallentamento di cui non si conosce la causa o di scoprire dove si verifica un’instabilità.

Da cosa nasce la necessità di mappare i ritardi?

Allocchio: Nasce dall’esigenza di qualsiasi applicazione real-time di conoscere lo stato di latenza e jitter lungo un backbone ed in generale lungo un percorso end-to-end. Lavorando con strumenti molto sensibili al tempo, come LoLa, ci siamo resi conto che c’erano dei problemi punto-punto ma non ne capivamo la causa: vedevamo solo il segnale degradato. L’unico modo per fare il debugging era di “smontare” la rete, segmento per segmento, per capire dove fosse il problema, avendo come unico indizio le latenze istantanee della singola tratta. Era evidente che servisse un sistema più efficace per riuscire a tracciare la causa dell’anomalia.

Come funziona?

Farina: Con un’applicazione tradizionale, per effettuare il monitoraggio è sufficiente intervenire in modo attivo: se servono 400 Mbps costanti, basta iniettare dati sintetici in un canale di rete per verificare che il valore nominale sia mantenuto. Con le applicazioni real-time questo non si può fare a priori, perché sebbene esistano dei test endto-end istantanei, latenza e jitter sono parametri di rete molto sensibili a fattori esogeni, come un cambiamento di routing. Ciò che accade è che facendo ora un test per un ipotetico concerto a distanza (LoLa) che deve aver luogo domani potremmo avere dei risultati ottimali, mentre stanotte i protocolli di routing potrebbero cambiare le rotte e ciò avrà un impatto su latenza e jitter della sessione LoLa, a parità di capacità.

Timemap mantiene delle serie storiche per tutti i link e a partire da certi punti distribuiti sulla rete verso tutti i router della rete. Ciò permette di averne una visione d’insieme più precisa rendendone evidente l’andamento, anche per settimane o mesi addietro. Così si riesce ad individuare i cambiamenti improvvisi sui valori mediati che danno degli indizi per individuare i fenomeni della rete che influiscono su latenza e jitter. Quasi mai questi parametri sono influenzati da eventi che si verificano direttamente sul percorso del segnale, quanto da fenomeni avvenuti nel resto del sistema, come un cambiamento di routing. Avere la visione d’insieme permette di capire dove cercare la causa dell’instabilità.

Un passo successivo è quello di dotare il prototipo di intelligenza, generando un allarme quando ci sono dei comportamenti critici (più o meno come si fa con i sistemi anti-DDOS). Per fare ciò, gli algoritmi che stiamo studiando sono due. Gli algoritmi di identificazione delle anomalie di latenza e/o jitter, che aiutano ad individuare un evento puntuale permettendo di identificare eventuali configurazioni errate o comportamenti non voluti della rete. Un altro tipo di algoritmo è legato alla variazione delle medie mobili, cioè partendo dalla latenza media in una rotta, con una fluttuazione fisiologica entro certi margini di jitter, è possibile individuare quando il valore della media cambia significativamente. Così si possono intercettare i cambiamenti lenti ma che influiscono sensibilmente sulle medie mobili.<7p>

Stiamo parlando di un prodotto da installare?

Farina: Non proprio. Quando ci siamo posti il problema di misurare i parametri di latenza e jitter, ci siamo chiesti quale fosse il modo più semplice e sostenibile per farlo, in modo che anche altre reti della ricerca nazionali potessero facilmente adottarlo. Abbiamo fatto delle scelte di apertura: sia gli strumenti software (lato server) e sia la piattaforma di raccolta ed integrazione dei dati sono basati su strumenti open source che sono lo standard de facto per l’analisi e collezione delle serie storiche. In accordo con il team Operations di GÉANT abbiamo deciso di adottare degli standard ben definiti per la raccolta e il monitoraggio dei parametri sensibili al tempo. In particolare abbiamo adottato il TWAMP (two-way advanced monitoring protocol). Si tratta di uno standard che tutti i costruttori di router di fascia alta stanno via via introducendo nei loro prodotti. In questo modo fare un’unica query a tutti i router diventa facile.

Allocchio: Non abbiamo sviluppato un codice, un software. L’obiettivo è quello di focalizzarci sui dati, integrando lo stato dell’arte dei sistemi di monitoraggio, in modo che nel momento in cui vengono installati e configurati dei nuovi router, seguendo una linea guida, ci si ritrovi ad avere lo strumento di diagnosi senza dover fare altro. L’idea è di creare uno standard di pratica: non vogliamo convincere le altre reti ad usare gli stessi strumenti, bensì vogliamo accordarci sui protocolli da monitorare e le interfacce open source da utilizzare per essere sicuri di parlare la stessa lingua.

A che punto siamo nel progetto?

Allocchio: Questo prototipo è il risultato di un’attività di GN4-3, in cui GARR si è occupato del lavoro di sviluppo e di liaison con i singoli attori di GÉANT e con le altre NREN. Il progetto era previsto per 2 anni, durante i quali dovevamo dimostrare che si poteva realizzare un sistema di misurazione di questo tipo, ciò è stato fatto con Timemap. In seguito è stata approvata l’estensione per altri 2 anni durante i quali dovremo lavorare a stretto contatto con GÉANT per la messa in produzione. Ciò apre altri tipi di questioni da risolvere, come decidere dove mantenere i dati del monitoraggio, ma dovremmo concludere questa fase entro la fine del 2021. Nell’anno successivo ci occuperemo dello sviluppo del sistema di allarmistica automatica e poi ovviamente le attività di outreach nei confronti delle altre NREN.

Quali sono i risultati attesi?

Allocchio: Prima di tutto, contiamo sul fatto che, grazie a Timemap, gli operatori di rete diventino consapevoli dell’instabilità di alcune tratte, in modo da poter porre rimedio ad eventuali misconfigurazioni. Al momento Timemap è installato come proof of concept sul backbone di GÉANT ma, affinché funzioni, serve arrivare a tutte le NREN altrimenti continueremo a fare debugging per esclusione. Con Timemap si riuscirebbe a velocizzare questa attività passando da alcuni giorni a qualche minuto!

È però necessario riuscire a coinvolgere tutte le reti e non è facile, in quanto ognuna è diversa, per organizzazione e tecnologia. Credo però che, con l’aumentare della diffusione di applicazioni real-time in ambiti sempre più vari, come la misurazione del tempo-frequenza o la telechirurgia, l’esigenza si farà sentire e, con essa, l’adesione da parte delle varie reti.

Guardando al futuro, però, si nota un’altra utilità di Timemap. Oltre al supporto al debugging, infatti, esso può essere visto anche come strumento di ottimizzazione dei percorsi di rete. In futuro, con delle reti di nuova generazione, sarà possibile pensare a delle reti (VPN) personalizzate in funzione dell’uso che gli utenti vorranno farne. Ad esempio, per una performance musicale o un esperimento si potrebbe pensare a delle reti adatte al real-time da fruire in modalità on-demand, o a delle connessioni progettate ad hoc per le accademie di musica e organizzazioni affini.

L’idea è una personalizzazione della rete, fatta su misura delle caratteristiche dell’utenza. In gergo questo modo di ripensare il percorso di rete in funzione dell’uso è detto segment routing. Possiamo allora dire che Timemap è uno strumento abilitante per arrivare al segment routing.