Quando si utilizza una rete globale di grandi dimensioni, garantire una buona connettività e prestazioni tra i sistemi che comunicano tramite Internet pubblico è fondamentale per garantire un’esperienza utente positiva. Data la natura complessa e di grande impegno di Internet, anche i collegamenti con il provisioning più adeguato sui provider più affidabili talvolta presentano problemi.
Esistono diverse strategie per monitorare tali collegamenti, tra cui la misurazione attiva , che genera traffico specifico per la misurazione, e la misurazione passiva , che monitora il traffico esistente. In questo articolo viene descritto un approccio passivo che utilizza il nostro sistema di campionamento socket xTCP per monitorare passivamente molti di questi collegamenti da cui dipende la nostra rete.
Per sfruttare al massimo i dati di xTCP, abbiamo ulteriormente sviluppato un approccio all’elaborazione di questi dati che affronta alcune delle sfide associate al monitoraggio di Internet. In particolare, introduciamo un concetto che chiamiamo rapporto di ritrasmissione , che fornisce una misura relativa della gravità delle ritrasmissioni osservate tra siti CDN (rete per la distribuzione dei contenuti). Abbiamo dimostrato che il rapporto di ritrasmissione al di sopra di determinati livelli corrisponde a degradazioni del throughput, con un impatto diretto sulle prestazioni percepite dagli utenti, rendendolo quindi una base eccellente per l’automazione della rete che ci consente di risolvere i problemi di riduzione delle prestazioni della rete.
Sfondo
Un flusso di lavoro comune nella CDN prevede che un punto di presenza (POP) raggiunga un altro per qualche parte del contenuto, ad esempio per recuperare una parte del contenuto nella cache. Spesso queste interazioni vengono effettuate in risposta diretta a una richiesta client, il che significa che la richiesta downstream potrebbe essere in attesa del completamento del trasferimento. In generale, le richieste stesse possono essere piuttosto piccole, nell’ordine di pochi kilobyte. Le risposte possono essere di dimensioni molto variabili, da kilobyte a molti megabyte.
Fig. 1: Il flusso delle richieste invia piccole richieste (KB dell’ordine) e riceve risposte potenzialmente grandi (potenzialmente megabyte).
Al fine di monitorare lo stato delle connessioni tra i punti di presenza, siamo in grado di utilizzare il nostro strumento di monitoraggio socket, xTCP, per campionare lo stato corrente di tutti i socket aperti sui nostri edge server. Sebbene ciò fornisca visibilità critica nei nostri socket client-facing, questi dati socket ci forniscono anche una visione dei dati tra pop.
Tuttavia, la misurazione di questi dati non è priva di alcune sfide. Innanzitutto, xTCP fornisce un campione point-in-time di connessioni diverse. Ciò significa che potremmo prendere molte connessioni in molti punti diversi della trasmissione. Pertanto, qualsiasi valutazione che faremo dovrà considerare la più ampia distribuzione dei comportamenti, piuttosto che qualsiasi singolo valore.
In secondo luogo, dobbiamo assicurarci di monitorare la direzione corretta. Mentre sia il POP che ha generato la richiesta (POP A nel diagramma precedente) che il POP che ha ricevuto la richiesta e deve rispondere ad essa (POP B sopra) hanno informazioni socket, i loro carichi di lavoro asimmetrici indicano che ci si aspetta un comportamento diverso: La maggior parte dei pacchetti inviati dal client saranno pacchetti di controllo (la richiesta iniziale, i pacchetti di conferma successivi), mentre la maggior parte dei pacchetti inviati dal server saranno pacchetti di dati, che probabilmente contengono volumi significativi di dati.
Di conseguenza, in caso di congestione o altri problemi lungo il percorso, è più probabile che i pacchetti che trasportano i dati, e quindi occupano più spazio nella coda, si verifichino perdite di pacchetti e subiscano ritrasmissioni, ad esempio a causa della caduta della coda su un router occupato. Per dimostrarlo, consideriamo la distribuzione delle velocità di ritrasmissione dei pacchetti (calcolata come il rapporto tra i pacchetti ritrasmessi totali diviso per il numero totale di segmenti di dati inviati, meno ritrasmissioni) visto nei flussi di richiesta e risposta tra una coppia di POP per un periodo di 10 minuti.
Fig. 2: Il traffico di risposta incontra più ritrasmissioni, probabilmente a causa delle loro dimensioni maggiori.
Qui, vediamo che i socket di richiesta client non ricevono ritrasmissioni quasi nulla durante questo periodo di tempo. D’altra parte, le risposte mostrano che quasi il 85% dei socket ha ritrasmissioni diverse da zero, tuttavia, notiamo che la velocità di ritrasmissione è ben al di sotto dell’1% per la maggior parte delle connessioni. Non sorprende che osserviamo un comportamento simile in quasi tutte le coppie di POP con ritrasmissioni diverse da zero durante il periodo di prova. Ci concentriamo quindi sui flussi di risposta carichi di dati. Dal momento che ci occupiamo di soddisfare le richieste ai POP di richiesta originali, ci riferiamo a questi come flussi “in entrata”.
La nostra sfida finale deriva da alcune complessità generali relative alle ritrasmissioni e dalla difficoltà di utilizzarle come segnale per il deterioramento delle prestazioni. In effetti, le ritrasmissioni possono avvenire regolarmente senza indicare un problema particolare, in quanto riflettono semplicemente lo stato del mittente e il numero di volte in cui un pacchetto è stato inviato di nuovo. Questi possono essere il risultato di altri complessi comportamenti di protocollo oltre alla perdita (ad esempio, il rilevamento della perdita di coda ). Ad aumentare la complessità, osserviamo che molti socket non osservano mai ritrasmissioni. Ciò significa che le sintesi ingenue (ad esempio, prendendo la mediana) possono portare a riassunti molto conservatori della velocità di ritrasmissione, e i riassunti distorti (ad esempio il 95° o il 99° percentile) possono in gran parte catturare comportamenti che non sono dannosi per la popolazione in generale.
Rapporto di ritrasmissione
Per semplificare l’impatto di queste sfide, consideriamo una metrica composita che chiamiamo rapporto di ritrasmissione. Ispirata al rapporto HD di Meta , che mira a quantificare la frazione di clienti che sono in grado di trasmettere video HD, questa misura cerca di descrivere la frazione di socket che stanno sperimentando un livello malsano di ritrasmissioni. Poiché a volte si prevedono ritrasmissioni diverse da zero, si definisce il rapporto di ritrasmissione come segue:
Questo valore è particolarmente facile da calcolare con i dati resi disponibili tramite xTCP. Nella nostra esperienza operativa, abbiamo scoperto che i valori del rapporto di ritrasmissione sono generalmente piccoli su collegamenti sani, evitando al contempo le sfide quasi sempre zero presenti nelle misurazioni della velocità di ritrasmissione grezza.
Abbiamo anche trovato la misurazione sensibile, spesso generando avvisi prima di altri sistemi di monitoraggio delle prestazioni. Ciò lo rende particolarmente utile quando si diagnosticano rapidamente i degradamenti della rete, che spesso iniziano con piccoli problemi che alla fine si trasformano in problemi più grandi.
Convalida della metrica
Al fine di dimostrare che il rapporto di ritrasmissione è direttamente correlato alle prestazioni dell’applicazione, si dimostra la sua efficacia prendendo in considerazione due misurazioni. In primo luogo, si dimostra che durante i periodi di elevato rapporto di ritrasmissione, l’applicazione client (il richiedente) registra un throughput inferiore rispetto ai periodi con un rapporto di ritrasmissione basso o zero. In secondo luogo, mostriamo che un elevato rapporto di ritrasmissione corrisponde spesso a degradazioni in altri segnali di rete, in particolare le sonde ICMP tra POP.
Per esaminare gli impatti sulle prestazioni delle applicazioni, ci rivolgiamo alle misurazioni effettuate esplicitamente dal livello dell’applicazione. In particolare, consideriamo i throughput misurati al POP del cliente, in quanto rappresentano la velocità di consegna funzionale raggiunta nel processo di invio dei dati. Per comprendere l’impatto degli eventi di ritrasmissione, abbiamo condotto il seguente studio su un paio di POP nel corso di una settimana, durante il quale si è verificato un problema significativo del fornitore.
In primo luogo, consideriamo tutti i periodi in cui si è verificato un evento di ritrasmissione. Si definisce un evento di ritrasmissione come qualsiasi periodo di tempo in cui il rapporto di ritrasmissione tra una coppia di POP si trova entro un determinato intervallo per almeno dieci minuti consecutivi. Sebbene ciò escluda gli eventi di breve durata, fornisce informazioni sul comportamento degli eventi più lunghi. Per ogni evento di ritrasmissione, vengono quindi raccolti i valori di throughput corrispondenti durante l’evento. Come controllo, raccogliamo dati per la stessa durata dell’evento, ma tre ore prima. Questo ci dà due serie di misurazioni della produttività: Gli eventi di ritrasmissione “durante” e “normale”, rilevati durante i periodi di non ritrasmissione. Normalizziamo quindi le misurazioni “durante” con il throughput mediano raggiunto tra i POP durante il tempo normale. Per quanto riguarda le nostre soglie, consideriamo quattro intervalli: Superiore a 0 ma inferiore al 25%, superiore a 25 ma inferiore al 50%, superiore a 50 ma inferiore al 75% e infine superiore al 75%.
Fig. 3: Il throughput relativo rispetto ai periodi di non ritrasmissione, osservati durante ogni evento di ritrasmissione.
La figura precedente mostra la distribuzione delle rese relative osservate durante il periodo di misurazione. In primo luogo, vediamo che anche nella fascia più bassa, il 60% delle transazioni ha raggiunto un throughput inferiore rispetto alla media. Considerando i rapporti di ritrasmissione più elevati, il throughput continua a diminuire, con un rapporto di ritrasmissione più elevato corrispondente a un throughput più basso e, nel peggiore dei casi, una diminuzione relativa mediana di oltre un ordine di grandezza. Queste misurazioni chiariscono che il rapporto di ritrasmissione cattura con successo le scarse prestazioni dei flussi interessati.
Passiamo ora a come questi eventi si correlano alle nostre misurazioni ICMP attive tra POP. In questo caso, consideriamo il comportamento di alcuni dei nostri monitoraggi attivi, che eseguono regolari sondaggi ICMP tra POP, per misurare eventuali perdite o cambiamenti nei modelli di ritardo. Per questa analisi, usiamo nuovamente gli eventi estratti dal confronto della produttività. Questa volta, tuttavia, esaminiamo la perdita misurata dall’ICMP per i periodi di tempo di ciascuna soglia, dove normale in questo caso non ha osservato alcuna perdita. Si noti che le limitazioni nella nostra analisi ICMP determinano una granularità di perdita del 2% per queste particolari misurazioni.
Fig. 4: Perdita di ICMP osservata in ciascun periodo di tempo. Un rapporto di ritrasmissione maggiore corrisponde a una perdita maggiore.
In questo caso, vediamo che le soglie inferiori raramente mostrano perdite, con il 90% delle misurazioni che non rilevano. Al contrario, alla soglia del .75, il 80% delle misurazioni ha osservato una perdita e ha osservato una perdita mediana relativamente elevata del 4%. In modo critico, notiamo i livelli in cui il rapporto di ritrasmissione corrispondeva a impatti significativi sul throughput (ad esempio 0,25) comportano una perdita minima nelle metriche ICMP. Questi risultati ribadiscono l’importanza di misurare le prestazioni del percorso al di là delle semplici sonde ICMP ed evidenziano la capacità del rapporto di ritrasmissione di offrire una visione sfumata delle prestazioni dei flussi effettivi su Internet.
Conclusioni e oltre
In questo post, abbiamo dimostrato il valore del rapporto di ritrasmissione, una pratica metrica di riepilogo che può essere facilmente calcolata con i dati disponibili anche dai dati del socket xTCP. La Corte ha inoltre dimostrato che fornisce informazioni chiare sui casi in cui le prestazioni delle applicazioni sono influenzate e gli interventi di rete sono necessari.
Il rapporto di ritrasmissione è diventato una parte fondamentale del nostro processo di monitoraggio, fornendo informazioni chiare sulle prestazioni del sistema, senza la necessità di elaborare registri delle applicazioni più grandi e ingombranti o affidarsi a sonde ICMP che non sono in grado di rilevare alcuni impatti.
Il nostro lavoro in corso sta esplorando in che modo la metrica può essere resa il più sensibile possibile per fornire un allarme tempestivo in caso di degradazioni, fornendo al contempo un input adeguato per sistemi di automazione più complessi.
Un ringraziamento speciale ai team di progettazione dell’architettura e dell’affidabilità della rete per il loro supporto in questo lavoro!
Per i ricercatori interessati a saperne di più su Edgio Labs & Advanced Projects o interessati ad esplorare lavori collaborativi su uno degli argomenti sopra descritti, contattare il team all’indirizzo research@edg.io.
