Home Articoli tecnici Come utilizzare le metriche RTT per migliorare le prestazioni di streaming
Applications

Come utilizzare le metriche RTT per migliorare le prestazioni di streaming

About The Author

Outline

Lo streaming di qualità dei video dipende da milioni di cose che vanno bene, come la gestione di un carico di lavoro in costante fluttuazione o la gestione di “folle improvvise” quando un gran numero di spettatori entra in un flusso contemporaneamente. Ecco perché la distribuzione di un flusso video affidabile e di alta qualità come parte di un servizio a pagamento, in cui gli spettatori si aspettano un’esperienza simile alla TV, richiede strumenti e metriche per articolare con precisione le sfide prestazionali, in modo da poter sapere dove e come risolvere i problemi.

Le CDN sono una soluzione indispensabile per lo streaming video perché offrono scalabilità a bassa latenza on demand in tutto il mondo. Oltre alle ottimizzazioni che migliorano il modo di lavorare, la CDN bilancia la crescita caotica del pubblico che può accompagnare un live streaming, per offrire prestazioni eccellenti all’utente finale è necessario un ulteriore livello di visibilità, metriche, strumenti e automazione.

In questo post, esamineremo esempi di recenti ottimizzazioni delle prestazioni che abbiamo realizzato per un grande servizio di streaming vMVPD nordamericano, tra cui:

  • Metriche utilizzate per migliorare/risolvere i problemi di prestazioni
  • Come definire le prestazioni e come misurarle
  • Ottimizzazioni continue per migliorare le prestazioni video

Numeri di sistema autonomo: La complessità dietro il sipario

Il Web moderno è costruito intorno a più livelli interconnessi di reti note come ASN (numeri di sistema autonomi), ciascuno costituito da grandi gruppi di indirizzi IP accoppiati con CDN (reti di distribuzione dei contenuti) che riducono la congestione rendendo i contenuti disponibili alla periferia della rete. Essenzialmente, come mostrato di seguito, Internet è costituito da una rete di reti, ognuna con il suo modello di business e le sue priorità uniche.

Fonte: Research Gate

Insieme alla complessità intrinseca delle ASN che interagiscono tra loro è la loro portata e la loro portata. Lo strumento vizAS tenta di visualizzare le interconnessioni tra i numerosi ASN su base paese per paese. Ad esempio, solo negli Stati Uniti, ci sono 16.979 ASN e 24.905 relazioni di peering attraverso le reti. A livello globale, sono presenti più di 90.000 ASN.

https://stats.apnic.net/vizas/index.html

Dal nostro punto di vista di provider di CDN, la complessità della connessione a migliaia di ASN è aggravata dalla necessità di soddisfare i requisiti di prestazioni di ciascun cliente, il profilo di utilizzo, il tipo di traffico e molti altri fattori. Ad esempio, un servizio come Twitter avrà un profilo di utilizzo o un footprint molto diverso rispetto a un’azienda di gaming che ha lanciato un aggiornamento importante. Analogamente, un’emittente che trasmette in streaming un evento sportivo dal vivo ha un profilo diverso rispetto a un servizio di streaming on demand. Anche due servizi di live streaming hanno probabilmente profili diversi, ognuno dei quali richiede un’ottimizzazione personalizzata delle prestazioni.

Dietro le quinte, abbiamo un gran numero di impostazioni di configurazione che possiamo regolare e ottimizzare per aiutare i clienti a raggiungere i loro obiettivi e requisiti prestazionali. Per alcuni, le prestazioni potrebbero essere ciò che si aspettavano (o meglio) dall’inizio, e non abbiamo bisogno di cambiare nulla. Altri possono avere obiettivi specifici, come TTFB più veloce (Time to First byte), un’importante metrica per i servizi di streaming, che devono essere affrontati.

Data la complessità e le dimensioni di Internet, è impossibile fornire miglioramenti delle prestazioni utili e coerenti attraverso approcci “whack-a-mole” o “scattershot”. I vantaggi reali derivano dalla raccolta completa dei dati e dall’analisi intensiva dei dati per identificare la causa principale di un problema o per ottenere informazioni proattive sulle modifiche alla configurazione di rete che andranno a vantaggio di un cliente.

Fornire informazioni RTT con Stargazer

Una delle metriche più importanti per determinare la latenza della rete e lo stato complessivo delle prestazioni è l’RTT (round-trip time). Questa è definita come la durata, misurata in millisecondi, che impiega un pacchetto per spostarsi dall’origine alla destinazione e una risposta per essere inviata nuovamente all’origine. Può essere utilizzato per diagnosticare e migliorare le prestazioni di rete su diversi vettori, tra cui congestione, problemi hardware, configurazioni errate e problemi di routing.

Data l’importanza di questa metrica, abbiamo creato un sistema interno chiamato Stargazer che utilizziamo per aggregare i dati RTT provenienti da varie fonti, inclusi i nostri sensori, i dati importati dai clienti e terze parti che monitorano anche le informazioni RTT. Stargazer monitora i tempi di risposta in uscita diretti al client. Altre fonti di dati possono includere tabelle BGP (Border Gateway Protocol) dai router, mappatura dei router a posizioni geografiche, registri RTT per le connessioni dai client e informazioni sul volume di traffico. Inoltre, il sistema può eseguire sonde attive come traceroutes e ping, se necessario.

Dietro l’attività di monitoraggio, Stargazer, in combinazione con altri strumenti che abbiamo sviluppato, ci consente di interrogare tutti i dati che abbiamo raccolto e di eseguire analisi approfondite che aprono le porte a miglioramenti continui. I nostri amministratori di rete possono utilizzare queste informazioni per isolare i problemi e identificare i percorsi o le configurazioni di rete per ottimizzare le prestazioni per obiettivi e requisiti specifici del cliente. E, come verrà discusso più avanti, è anche utile per capire l’effetto che le nuove tecnologie, come il protocollo BBR (BBleneck Bandwidth and Round-trip propagation Time), hanno sulle prestazioni.

Ottimizzazione di un server di origine

Per fornire maggiori informazioni sul funzionamento pratico dell’ottimizzazione delle prestazioni, diamo un’occhiata ad un esempio che coinvolge un cliente di streaming video live aggiunto di recente che aveva bisogno di ottimizzare per un ‘architettura multi-CDN. In un’architettura client CDN tradizionale, il client effettua una richiesta a uno dei nostri POP e la cache POP si riempie dall’origine, come mostrato di seguito.

Tuttavia, questo cliente ha scelto di sfruttare un’architettura multi-CDN per aumentare la ridondanza e la resilienza e potenzialmente aumentare le prestazioni. Questo è attivato dalla nostra architettura Origin Shield illustrata nella Figura 4. Origin Shield offre un maggiore controllo sul modo in cui il traffico dei vari client può essere instradato per ottenere le migliori prestazioni.

A differenza di una relazione CDN tradizionale, tutto il traffico, incluso quello servito dalla seconda CDN, torna a uno dei nostri POP (AGA) situati ad Atlanta per il riempimento della cache. L’AGA POP serve quindi come origine, o più specificamente, ciò che è noto come lo scudo di origine, alleviando il notevole carico dal server di origine del cliente. L’AGA POP è stato scelto come posizione dello shield di origine a causa del suo rapporto cache-hit e delle prestazioni più elevate rispetto alla seconda CDN. Una preoccupazione importante, tuttavia, era l’ottimizzazione delle prestazioni tra le due CDN.

Il primo passo del processo è stato quello di cercare di ottimizzare i percorsi intrapresi dalla seconda CDN verso AGA, agendo come scudo di origine. Un problema immediatamente apparente era rappresentato dalle scarse prestazioni tra le CDN e da un elevato numero di timeout di connessione che influivano sul TTFB. Per analizzare i problemi di prestazioni, abbiamo utilizzato Stargazer per inviare un traceroute da AGA alla destinazione prevista e acquisire gli ASN utilizzati per ogni hop.

Come illustrato nel riepilogo di seguito, un traceroute è stato inviato da AGA a un indirizzo IP presso il secondo CDN, simulando il percorso del cliente.

Abbiamo notato che all’interno dell’ASN 7018 erano presenti diversi salti, che non era la strada preferita perché comportava più salti e una maggiore congestione. Utilizzando Stargazer, abbiamo rapidamente confermato il problema e apportato le modifiche appropriate alla rete. Come mostra il riepilogo traceroute riportato di seguito, dopo aver apportato la modifica alla rete, abbiamo ridotto il numero di hop e migliorato il RTT passando ad ASN 7922, che ha risolto anche il problema con i timeout TTFB.

In un altro esempio, abbiamo utilizzato lo strumento Stargazer per determinare il miglior percorso dello shield di origine per il server di origine di un cliente situato sulla costa orientale. Per ridurre efficacemente il carico sull’origine di un cliente e migliorare le prestazioni di consegna, il pop dello scudo dell’origine deve essere vicino all’origine. A volte, non è necessariamente il pop fisico più vicino che funziona meglio. È una combinazione del minor numero di ASN, la minore quantità di congestione e bassi tempi di RTT. Come si può vedere nella prima e dopo la tabella sottostante, un traceroute Stargazer ha mostrato che il passaggio dal pop NYA (New York) al pop DCC (Washington, D.C.) ha ridotto il numero di hop a tre, con un conseguente miglioramento complessivo delle prestazioni RTT.

Analisi più approfondita con Sweeper Fish

Con oltre 7.000 interconnessioni e oltre 300 POP in tutta la nostra CDN in tutto il mondo, è in corso un’ampia attività di ottimizzazione. Per evitare di far girare le ruote su attività che potrebbero non fare molta differenza, avevamo bisogno di un modo efficiente per dare priorità alle azioni intraprese dai nostri team operativi. Questa necessità ha portato allo sviluppo di uno strumento complementare a Stargazer chiamato Sweeper Fish, che segna i luoghi in cui esistono problemi e ci consente di rigenerarli in modo prioritario.

Sweeper Fish è anche utile per determinare se un percorso è congestionato e se è probabile che causi problemi. Tornando all’esempio della rete multi-CDN, abbiamo utilizzato Sweeper Fish per scoprire quali percorsi avevano una congestione. Per fare questo, Sweeper Fish ha misurato il delta tra il 25° e il 75° percentile per i dati RUM (Real User Measurement) per tutti i clienti su tutti i percorsi verso l’AGA POP, concentrandosi sul percorso della seconda CDN verso di noi, ASN7922. La deviazione standard per tutto il traffico su questo ASN è mostrata di seguito.

Abbiamo anche confermato che la configurazione precedente tramite ASN7018 non era la strada da percorrere. L’analisi Sweeper Fish ha mostrato che l’IQR (Interquartile Range) ha raggiunto un picco di 20-60 – millisecondi (vedere la Figura 9) a causa della congestione su questo percorso. IQR, chiamato anche midspread o Middle 50%, fornisce un modo utile per analizzare rapidamente un percorso e segnalare i problemi. Più basso è l’IQR, meglio è.

Al contrario, l’AGA POP era costantemente tra i 10-22 millisecondi sul percorso che abbiamo finito per utilizzare, ASN7922, come mostrato di seguito. Confrontando diversi ASN, Sweeper Fish ci consente di scegliere il percorso migliore e meno congestionato e/o identificare i problemi da risolvere.

Sintonizzazione TCP

La congestione causa inoltre l’abbandono e la ritrasmissione dei pacchetti. Ciò si verifica quando i percorsi tra i POP sono distanti e l’algoritmo TCP non è ottimizzato. Poiché AGA è stata l’origine del nostro esempio, è stato possibile che i POP lontani che hanno raggiunto AGA avessero questo problema. Anche se distribuiti in molti POP, i registri CDN aggregati riportati di seguito ci hanno consentito di identificare le aree problematiche come indicato nelle caselle.

Figura 11. I registri server aggregati identificano rapidamente le aree problematiche in cui i pacchetti vengono rilasciati e ritrasmessi.

Valutazione BBR

La larghezza di banda dei colli di bottiglia e il tempo di propagazione di andata e ritorno (BBR) sono un algoritmo di controllo della congestione TCP alternativo sviluppato da Google che ha iniziato a guadagnare una certa trazione. Si differenzia dagli algoritmi di controllo della congestione basati sulla perdita, come l’onnipresente TCP-Cubic, e introduce un paradigma operativo diverso. Aggiorna continuamente la quantità di dati che possono essere in volo in base all’RTT minimo che la sessione ha visto finora per evitare il bloat del buffer.

La nostra analisi ha rilevato che BBR è utile per migliorare le prestazioni RTT ma non è una soluzione universale. Ci sono alcune volte in cui vuoi usarlo e altre volte in cui non lo fai Stargazer ci aiuta a determinare quando vogliamo utilizzarlo monitorando il profilo coerente degli RTT per le destinazioni nel corso dei periodi. Ciò ci consente di determinare i punti migliori per applicare BBR per ridurre le ritrasmissioni e migliorare il controllo del flusso.

In base all’analisi mostrata nei grafici riportati di seguito, abbiamo concluso che il passaggio a BBR migliorerebbe leggermente le prestazioni dell’AGA POP alla seconda CDN e all’origine del cliente. La prima serie di grafici mostra che il passaggio da TCP-Cubic a TCP BBR ha comportato una diminuzione delle ritrasmissioni, mentre la seconda serie di grafici indica che la modifica a BBR ha fornito un leggero aumento della velocità di trasmissione media.

Figura 12. In questo esempio, il passaggio da TCP-Cubic a TCP BBR ha comportato una diminuzione delle ritrasmissioni

Figura 13. In questo esempio, il passaggio a BBR per il controllo del flusso da TCP-Cubic per l’AGA POP ha ridotto le ritrasmissioni e migliorato leggermente il throughput medio.

Conclusione

Internet è vasto e complesso – è essenzialmente una rete di reti. Per Edgecast, ora Edgio, l’ottimizzazione delle prestazioni per i casi di utilizzo dei clienti sarebbe quasi impossibile senza analisi approfondite per ottenere informazioni sulle aree problematiche e testare eventuali modifiche alla configurazione. Per migliorare le prestazioni dei nostri clienti, abbiamo sviluppato un solido set di strumenti per monitorare costantemente gli RTT, in modo da poter apportare miglioramenti in modo rapido ed efficiente in tutta la nostra rete. Per un servizio di streaming video live, abbiamo trovato modi per ottimizzare le prestazioni in base ai loro requisiti specifici, valutando al contempo l’uso di BBR per la loro applicazione. Il risultato è stata una soluzione di streaming ad alte prestazioni che sfruttava due CDN. E non abbiamo ancora finito. Poiché la congestione della rete continua ad aumentare, non smetteremo mai di ottimizzare la nostra rete per garantire ai nostri clienti e ai loro clienti la migliore esperienza online possibile.