Imposta un budget di ritardo per il traffico in tempo reale su una VPN

Le lamentele sulle VPN in tempo reale hanno bisogno di una scadenza rispetto a cui fallire, e «bassa latenza» non è una scadenza. Decidi cosa deve fornire la conversazione o la sessione remota, poi misura il percorso rispetto a quel requisito in condizioni dichiarate. Senza una soglia per i pacchetti in ritardo, ogni risultato è discutibile. La ripartizione qui sotto è una decisione di progettazione, ed esiste perché la misurazione abbia qualcosa a cui rispondere.

Scrivi la scadenza prima di toccare una sonda

La scadenza viene dall’applicazione e dai suoi utenti, non dalla pagina marketing di un fornitore. Una chiamata vocale in diretta, una sessione desktop remoto e un backup notturno tollerano tempi di attesa completamente diversi, e il guasto che conta è di solito la coda e non la mediana. Scrivi il numero insieme al carico di lavoro a cui appartiene.

Poi ripartiscila. Cattura e impacchettamento consumano parte del budget, il collegamento di accesso e il tunnel un’altra parte, il buffer di de-jitter del ricevitore trattiene i pacchetti di proposito e l’elaborazione dell’applicazione prende il resto. Dare un nome a queste fasi mantiene la crittografia del tunnel in proporzione invece di renderla il sospetto predefinito di ogni pacchetto lento.

Infine definisci il contratto di misurazione in quattro righe: estremi e direzione, forma del traffico, condizioni durante l’esecuzione e il risultato che comunicherai. Un campione di una domenica tranquilla e uno di un martedì carico rispondono a domande diverse, quindi indica quale hai raccolto. Se non riesci a compilare tutte e quattro le righe, l’esecuzione non è pronta per iniziare. Quella lista di controllo è anche ciò che rende confrontabili due rapporti mesi dopo, quando nessuno ricorda più che cos’altro stava trasportando il collegamento.

Ripartisci il budget su ogni fase

La tabella è un aiuto alla pianificazione, non dati catturati. Compila il proprietario per ogni riga prima della prima sonda, perché il proprietario è la persona che chiami quando quella fase supera la sua parte.

Due righe di solito sorprendono le persone. Il buffer del ricevitore non è un difetto quando aggiunge ritardo, perché fa il lavoro per cui è stato configurato. E la parte del tunnel è spesso più piccola della coda davanti a esso, soprattutto su un uplink che si satura durante i caricamenti.

Quando una fase non ha proprietario, il budget è finzione. Assegnane uno prima di misurare, altrimenti passerai la riunione successiva a discutere di quale numero sia sbagliato.

Misura il ritardo a senso unico con un orologio onesto

Il ritardo a senso unico è il numero a cui tiene la scadenza, e richiede orologi sincronizzati alle due estremità. La metrica del ritardo a senso unico richiede di riportare metodo di sincronizzazione, risoluzione e scostamento stimato accanto al risultato. Due host non sincronizzati possono produrre un numero molto preciso per la grandezza sbagliata.

Cattura qualche centinaio di pacchetti invece di una manciata, e registra lo stato dell’orologio nello stesso momento:

$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3

Il tempo di andata e ritorno è una misurazione separata, non due valori a senso unico sommati. Dimezzare un RTT presuppone percorsi simmetrici e code simmetriche, e un tunnel su un uplink mobile infrange regolarmente entrambe le ipotesi. Riporta l’RTT come RTT e tienilo fuori dal budget a senso unico.

Riporta la coda e i pacchetti in ritardo

Riassumi la distribuzione: mediana, 95° e 99° percentile, caso peggiore, perdita e il numero di pacchetti arrivati più tardi di quanto la scadenza consenta. La media è il meno utile di questi numeri per un carico di lavoro in tempo reale, perché una media uniforme può nascondere una coda che rovina ogni terza chiamata.

La variazione del ritardo alimenta direttamente il buffer del ricevitore. Più buffering nasconde la variazione e aggiunge attesa, così un flusso può sembrare stabile mentre supera la sua scadenza. Scegli una formulazione della variazione, indica l’intervallo su cui hai misurato e mantienila coerente tra le esecuzioni.

Ripeti l’esecuzione con traffico incrociato rappresentativo. Un percorso che rispetta il budget quando è inattivo e lo manca durante una finestra di backup ti ha detto qualcosa di utile sulla pianificazione, che nessuna singola misurazione silenziosa rivelerebbe. Annota le condizioni accanto al risultato, altrimenti il prossimo ingegnere confronterà due campioni che non sono mai stati confrontabili.

Accetta il progetto quando la coda misurata rientra nel budget sotto il carico di lavoro che esegui davvero, e rifiutalo indicando nel rapporto la fase che ha superato il limite.