Videoconferenza senza interruzioni: perché Hot Failover da solo non basta

Chi vuole mettere in sicurezza una videoconferenza pensa per prima cosa al guasto totale: l'escavatore, il blackout, il disservizio del provider. Nella pratica è il caso più raro. Ciò che rovina davvero una trasmissione in corso sono la perdita di pacchetti e le oscillazioni di latenza su una linea che formalmente resta "up".

L'ordine di grandezza aiuta a capire. Per l'invio di uno stream 1080p Zoom indica circa 3,8 Mbit/s in upload; una condivisione di presentazione in parallelo aggiunge da 50 a 150 kbit/s, il canale audio da 60 a 80 kbit/s. Una postazione di trasmissione professionale ha quindi bisogno di circa 4 Mbit/s in upload — su una connessione con 40 o 300 Mbit/s in upload è un errore di arrotondamento.

Proprio qui sta l'errore di ragionamento di molti concetti di protezione: la banda non è il problema. Il problema è l'uniformità della consegna. Un codec in tempo reale non può richiedere di nuovo un pacchetto perso e aspettarlo — la riproduzione va avanti. Se manca un pacchetto nasce un artefatto; se ne mancano diversi di seguito l'immagine si blocca o l'audio si interrompe. Il due per cento di perdita di pacchetti su una linea da 300 Mbit/s è invisibile per il download di un file e chiaramente udibile in una trasmissione dal vivo.

Da qui deriva il requisito vero e proprio: non si tratta di avere una linea di riserva. Si tratta del fatto che un errore sulla linea attiva non arrivi al destinatario.

Hot Failover è una modalità operativa del tunnel SpeedFusion. Il tunnel viene stabilito su tutte le connessioni WAN coinvolte e mantenuto attivo su tutte; il traffico utile però in ogni momento è trasportato solo dal percorso con la priorità più alta. Se questo cade, subentra il successivo.

Il vantaggio decisivo rispetto al failover classico senza tunnel: la sessione resta attiva. Poiché il traffico passa nel tunnel e il punto remoto conserva lo stesso indirizzo, l'applicazione non si accorge di alcun cambio di indirizzo. Non c'è un nuovo accesso, nessun reconnect, nessuna espulsione dal meeting. Per un sistema di conferenza è una grande differenza rispetto a un router che semplicemente cambia la rotta predefinita.

Ed ecco la lacuna di cui nelle offerte si parla raramente: la commutazione inizia solo quando il guasto è stato rilevato. Il rilevamento avviene tramite il monitoraggio delle linee e i keepalive del tunnel. La rapidità dipende dal prodotto fra intervallo di verifica e numero di ripetizioni prima che una linea venga considerata morta — più il tempo che richiede la commutazione stessa.

In questa finestra l'audio non c'è. Se siano tre, cinque o quindici secondi dipende da quanto aggressivamente è stato configurato il monitoraggio; i valori nel grafico in alto sono un tipico ordine di grandezza tratto dalla pratica e non un valore da scheda tecnica di Peplink. Impostazioni aggressive accorciano la finestra, ma aumentano il rischio di falsi allarmi in caso di un breve picco di latenza.

Ancora più importante: il caso di guasto più frequente non viene affrontato in alcun modo da Hot Failover. Una linea con il due per cento di perdita di pacchetti non è guasta. Supera ogni verifica, resta attiva e fornisce per tutto il tempo un'immagine scadente.

WAN Smoothing risolve lo stesso problema dal lato opposto. Invece di scegliere una linea e cambiarla in caso di guasto, il tunnel invia gli stessi pacchetti contemporaneamente su più linee. Il punto remoto prende la copia che arriva per prima e scarta i duplicati.

Questo ha tre conseguenze che si adattano esattamente a una trasmissione dal vivo:

• Non c'è alcuna commutazione. Se una linea cade in mezzo a una frase, il pacchetto è già arrivato da tempo attraverso l'altra. Nessuna finestra di rilevamento, nessuna lacuna — nemmeno i tre secondi.
• La perdita di pacchetti su una linea diventa invisibile, fino a quando i due percorsi non perdono lo stesso pacchetto nello stesso momento. Con linee tecnologicamente indipendenti è improbabile.
• La latenza scende a quella del percorso più rapido. Poiché vince sempre la prima copia, non risulta la media delle due linee ma il minimo. Una seconda linea lenta non peggiora quindi la connessione — può soltanto migliorarla.

Il prezzo è banda, in modo scalato e pianificabile. Il livello Normal raddoppia il volume di traffico, Medium lo triplica, High lo quadruplica; Maximum dipende dal numero di coppie di connessioni attive. Con la nostra postazione di trasmissione da 4 Mbit/s di carico utile, il livello Normal significa quindi 8 Mbit/s sulla connessione — su una linea business una questione marginale.

Importante è il punto di riferimento: l'overhead nasce solo per il traffico che passa nel tunnel con lo smoothing attivo. Chi attiva lo smoothing in modo indiscriminato per l'intero edificio raddoppia anche ogni download e ogni backup. Proprio per questo va messo su un sub-tunnel dedicato.

Tra "non fare nulla" e "inviare tutto due volte" si colloca la Forward Error Correction. Invece di trasmettere copie complete, FEC integra il flusso di dati con informazioni di correzione dalle quali il punto remoto può ricostruire i pacchetti perduti senza richiederli di nuovo.

L'overhead è così molto più contenuto. I livelli statici si attestano intorno al 13 per cento e al 27 per cento; la variante adattiva si regola dinamicamente circa tra il 7 e il 20 per cento, in funzione della perdita misurata. Invece di un raddoppio si paga quindi un sovrapprezzo nella fascia percentuale a due cifre bassa.

In cambio vale questa limitazione: FEC ricostruisce fino a quando l'informazione di correzione è sufficiente. In caso di guasto totale della linea o di una lunga raffica di perdite non basta — allora il pacchetto continua a mancare. FEC è quindi la scelta giusta quando la banda è scarsa o il percorso va in una sola direzione, per esempio in un livestream verso una piattaforma. Per una conferenza bidirezionale con la massima protezione dai guasti lo smoothing resta lo strumento più efficace — ed entrambi i metodi possono essere usati in parallelo su sub-tunnel separati.

Negli elenchi di requisiti si trova spesso una formulazione come: protezione tramite Hot Failover, in caso di necessità anche WAN Smoothing. Suona ragionevole e tecnicamente non è realizzabile, almeno non nel modo in cui è intesa.

WAN Smoothing è un'impostazione fissa nel profilo del tunnel, non un anello di regolazione. Non esiste alcun automatismo che si attivi da sé quando la latenza sale o la perdita di pacchetti aumenta. Chi pianifica "in caso di necessità" deve quindi definire lui stesso il caso di necessità — e ci sono esattamente tre risposte solide:

1. Sempre attivo per il sub-tunnel critico. L'overhead è noto e ridotto, il beneficio è sempre presente. Nella quasi totalità dei casi è la risposta giusta.
2. Su base oraria, legando a un profilo temporale la regola che indirizza il traffico nel tunnel con lo smoothing. Sensato quando il volume è limitato e gli orari di trasmissione sono fissi.
3. FEC sempre attivo, con lo smoothing solo per eventi definiti. Il compromesso per linee scarse.

La conclusione scomoda che ne deriva: una protezione che entra in funzione solo dopo il rilevamento di un problema non può mai impedire la prima comparsa del problema. Per una trasmissione dal vivo è proprio questa prima comparsa a costituire il danno.

La soluzione pulita separa il traffico critico dal resto, invece di raddoppiare tutta la rete. Con il firmware 8.0.1 Peplink ha introdotto a questo scopo i sub-tunnel: un link SpeedFusion può portare più sub-tunnel — ne sono documentati fino a cinque — e ognuno con un profilo proprio. Un tunnel, più comportamenti.

La configurazione nella pratica:

1. La postazione di trasmissione riceve un indirizzo fisso tramite una riserva DHCP e si trova in un VLAN dedicato. Senza un indirizzo stabile nessuna regola è affidabile.
2. Creare un sub-tunnel con WAN Smoothing, livello Normal come punto di partenza.
3. Una regola di traffico indirizza il traffico di questo singolo computer in quel sub-tunnel — l'assegnazione tramite l'indirizzo di origine è più robusta di una regola sulle porte, perché funziona indipendentemente da quali porte il software di conferenza userà nel prossimo aggiornamento.
4. Tutto il resto passa direttamente sulle linee o attraverso un secondo sub-tunnel in modalità Hot Failover. Backup e upload di grandi dimensioni ricevono inoltre un limite di banda, così da non soffocare la postazione di trasmissione.

Due punti su cui nella pratica si fallisce. Primo: un tunnel SpeedFusion ha sempre bisogno di un punto remoto — un secondo dispositivo Peplink, un FusionHub o il servizio ospitato SpeedFusion Connect. Senza controparte non c'è smoothing, ma solo distribuzione del carico. Secondo: sul volume dati non è affatto automatico — ciò che il tunnel con lo smoothing trasmette due volte conta due volte anche sul punto remoto. Come si fa il conto lo abbiamo calcolato in un articolo dedicato.

E la frase più importante alla fine, perché nello schema di rete non compare: la ridondanza delle linee protegge dai guasti delle linee. Non protegge da una postazione di trasmissione bloccata, da una scheda di acquisizione impallata o da un disservizio del fornitore della piattaforma di conferenza. Chi vuole davvero mettere in sicurezza una trasmissione mette anche computer e monitor sull'UPS e tiene pronto un secondo computer come co-moderatore.

Questo articolo è stato documentato e redatto con il supporto dell'IA e verificato prima della pubblicazione dai tecnici certificati Peplink di Ascend.