Home Blogs Misurazione del centro con il rapporto di ritrasmissione
Applications

Misurazione del centro con il rapporto di ritrasmissione

About The Author

Outline

Quando si utilizza una rete globale di grandi dimensioni, garantire una buona connettività e prestazioni tra 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 più ben forniti sui provider più affidabili talvolta presentano problemi.

Esistono diverse strategie per il monitoraggio di 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 collegamenti da cui dipende la nostra rete.

Per sfruttare al massimo i dati di xTCP, abbiamo sviluppato ulteriormente un approccio per elaborare 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 i siti della rete di distribuzione dei contenuti (CDN) . Abbiamo dimostrato che il rapporto di ritrasmissione al di sopra di determinati livelli corrisponde a degradazioni del throughput, che influiscono direttamente sulle prestazioni percepite dall’utente, rendendolo quindi una base eccellente per l’automazione della rete che ci consente di aggirare il deterioramento delle prestazioni della rete.

Contesto

Un flusso di lavoro comune nella CDN prevede che un punto di presenza (POP) raggiunga un altro punto per alcuni contenuti, ad esempio per recuperare un contenuto da memorizzare nella cache. Spesso queste interazioni vengono effettuate in risposta diretta a una richiesta del client, il che significa che la richiesta downstream potrebbe essere in attesa del completamento del trasferimento. Generalmente, 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 di richieste invia richieste di piccole dimensioni (KB dell’ordine) e riceve risposte potenzialmente grandi (potenzialmente megabyte).

Per monitorare lo stato delle connessioni tra i punti di presenza, possiamo 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 una visibilità critica nei socket destinati ai clienti, questi dati del socket ci forniscono anche una visione dei dati tra i POP.

Tuttavia, la misurazione di questi dati non è priva di alcune sfide. Innanzitutto, xTCP fornisce un campione point-in-time di diverse connessioni. Ciò significa che potremmo rilevare molte connessioni in molti punti diversi della trasmissione. Pertanto, qualsiasi valutazione che faremo dovrà considerare la più ampia distribuzione dei comportamenti, piuttosto che un singolo valore.

Poi, 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) dispongono di informazioni sul socket, i loro carichi di lavoro asimmetrici indicano che ci aspettiamo 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, i pacchetti che trasportano dati, e quindi occupano più spazio nella coda, hanno maggiori probabilità di perdere pacchetti e di subire ritrasmissioni, ad esempio a causa di interruzioni della coda su un router occupato. A dimostrazione di ciò, consideriamo la distribuzione delle velocità di ritrasmissione dei pacchetti (calcolate come il rapporto dei pacchetti ritrasmessi totali diviso per il numero totale di segmenti di dati inviati, meno ritrasmissioni) visibili 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.

In questo periodo di tempo, i socket delle richieste client non subiscono quasi alcuna ritrasmissione. D’altra parte, le risposte mostrano quasi il 85% dei socket con ritrasmissioni diverse da zero, tuttavia, si nota che la velocità di ritrasmissione è ben inferiore all’1% per la stragrande maggioranza delle connessioni. Non sorprende che si osservi un comportamento simile in quasi ogni coppia di POP con ritrasmissioni diverse da zero durante il periodo di test. Ci concentriamo quindi sui flussi di risposta carichi di dati. Dal momento che ci occupiamo di soddisfare le richieste ai POP di richiesta originali, li chiamiamo flussi “in entrata”.

La nostra sfida finale deriva da alcune complessità generali legate alla ritrasmissione e dalla difficoltà di utilizzarle come segnale per il degrado 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 reinviato. Questi possono essere il risultato di un altro comportamento complesso del protocollo oltre alla perdita (ad esempio, la perdita di coda). A ciò si aggiunge la complessità, si osserva che molti socket non osservano mai le ritrasmissioni. Ciò significa che i riepiloghi ingenui (ad esempio, prendendo la mediana) possono portare a riepiloghi molto conservativi della velocità di ritrasmissione, e i riepiloghi 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 in grado di trasmettere video HD in streaming, questa misura cerca di descrivere la frazione di socket che stanno sperimentando un livello non salutare di ritrasmissioni. Poiché a volte sono previste ritrasmissioni diverse da zero, definiamo il rapporto di ritrasmissione come segue:

In modo critico, 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 che la misurazione è sensibile, spesso generando avvisi prima di altri sistemi di monitoraggio delle prestazioni. Ciò lo rende particolarmente utile quando si diagnosticano rapidamente i degrado della rete, che spesso iniziano con piccoli problemi che alla fine si trasformano in problemi più grandi.

Convalida del sistema metrico

Per dimostrare che il rapporto di ritrasmissione è direttamente correlato alle prestazioni delle applicazioni, ne dimostriamo l’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) presenta un throughput inferiore rispetto ai periodi con un rapporto di ritrasmissione basso o zero. In secondo luogo, si dimostra che un elevato rapporto di ritrasmissione spesso corrisponde a degradazioni in altri segnali di rete, in particolare le sonde ICMP tra POP.

Per esaminare l’impatto sulle prestazioni delle applicazioni, passiamo alle misurazioni prese esplicitamente dal livello dell’applicazione. In particolare, prendiamo in considerazione 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 lo studio seguente su un paio di POP nel corso di una settimana, durante la quale si è verificato un problema significativo del provider.

In primo luogo, consideriamo tutti i periodi in cui si è verificato un evento di ritrasmissione . Definiamo un evento di ritrasmissione come qualsiasi periodo di tempo in cui il rapporto di ritrasmissione tra una coppia di POP si trova all’interno di un determinato intervallo per almeno dieci minuti consecutivi. Sebbene si noti che questo escluda gli eventi di breve durata, fornisce informazioni sul comportamento di eventi più lunghi. Per ogni evento di ritrasmissione, raccogliamo quindi i valori di throughput corrispondenti durante l’evento. Come controllo, raccogliamo i dati per la stessa durata dell’evento, ma tre ore prima. Questo ci fornisce due serie di misurazioni del throughput: Gli eventi di ritrasmissione “durante” e “normale”, acquisiti in periodi di assenza di ritrasmissioni. Normalizziamo quindi le misurazioni “durante” in base al throughput mediano raggiunto tra i POP durante il tempo normale. Per le nostre soglie, consideriamo quattro intervalli: Superiori a 0 ma inferiori al 25%, superiori a 25 ma inferiori al 50%, superiori a 50 ma inferiori al 75% e infine superiori al 75%.

Fig. 3: Il throughput relativo rispetto ai periodi di non ritrasmissione, osservato durante ogni evento di ritrasmissione.

La figura precedente mostra la distribuzione dei flussi relativi osservati durante il periodo di misurazione. In primo luogo, vediamo che anche nell’intervallo più basso, il 60% delle transazioni ha raggiunto un throughput inferiore rispetto alla mediana. Se consideriamo 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 si ottiene una diminuzione mediana relativa 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 alla correlazione di questi eventi con le misurazioni ICMP attive tra i 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, utilizziamo ancora una volta gli eventi estratti dal nostro confronto del throughput. Questa volta, tuttavia, consideriamo 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 del nostro test ICMP determinano una granularità di perdita del 2% per queste misurazioni particolari.

Fig. 4: La perdita di ICMP osservata durante ciascun periodo di tempo. Un maggiore rapporto di ritrasmissione corrisponde a una maggiore perdita.

In questo caso, vediamo che le soglie più basse raramente mostrano alcuna perdita, con il 90% delle misurazioni che non rileva alcuna perdita. Al contrario, alla soglia del .75, il 80% delle misurazioni ha osservato una perdita e una perdita mediana relativamente elevata del 4%. Criticamente, 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 oltre le semplici sonde ICMP e mettono in evidenza la capacità del rapporto di ritrasmissione di offrire una visione sfumata delle prestazioni dei flussi effettivi attraverso Internet.

Conclusioni e non solo

In questo post, abbiamo dimostrato il valore del rapporto di ritrasmissione, una comoda metrica di riepilogo che può essere facilmente calcolata con i dati disponibili anche dai dati del socket xTCP. Abbiamo inoltre dimostrato che fornisce informazioni chiare sui casi in cui le prestazioni delle applicazioni sono influenzate e sono necessari interventi di rete.

Il rapporto di ritrasmissione è diventato una parte fondamentale del nostro processo di monitoraggio, fornendo una visione chiara delle prestazioni del sistema, senza la necessità di elaborare log delle applicazioni più grandi e ingombranti o di affidarsi a sonde ICMP che non riescono a catturare alcuni impatti.

Il nostro lavoro in corso sta valutando come la metrica possa essere resa il più sensibile possibile per fornire un allarme tempestivo alle degradazioni, fornendo allo stesso tempo un input adeguato a 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 conoscere meglio i progetti Edgio Labs & Advanced o interessati ad esplorare lavori collaborativi su uno qualsiasi degli argomenti sopra descritti, contattare il team all’indirizzo research@edg.io.