Home Articoli tecnici Valutazione BBR presso una CDN di grandi dimensioni
Applications

Valutazione BBR presso una CDN di grandi dimensioni

About The Author

Outline

La larghezza di banda dei colli di bottiglia e il tempo di propagazione round-trip (BBR) sono un algoritmo di controllo della congestione TCP che ha guadagnato notevole attenzione sul mercato grazie alla sua capacità di offrire un throughput più elevato, come riportato da molti provider di contenuti. In questo post, valutiamo BBR (versione 1) nel contesto dei carichi di lavoro CDN (Content Delivery Network) di Verizon Media, ora Edgio, che fornisce volumi significativi (Tbps multipli) di aggiornamenti software e streaming video, e quantifichiamo i vantaggi e l’impatto sul traffico. Ci auguriamo che tale valutazione presso una CDN di grandi dimensioni possa aiutare altri fornitori di contenuti a scegliere il giusto protocollo di controllo della congestione per il loro traffico.

Contesto

Molti provider di contenuti e ricercatori accademici hanno scoperto che BBR fornisce un throughput maggiore rispetto ad altri protocolli come TCP-Cubic. A differenza degli algoritmi di controllo della congestione basati sulla perdita, come l’onnipresente TCP-Cubic, BBR ha un paradigma operativo diverso: Aggiorna continuamente quanti dati possono essere in volo in base al minimo RTT che la sessione ha visto finora per evitare bufferbloat. Per ulteriori informazioni sul funzionamento di BBR, date un’occhiata alla pubblicazione originale da Google qui.

Misurazioni e analisi

Per comprendere il potenziale di BBR presso la nostra CDN, abbiamo valutato BBR in più fasi, misurando l’impatto sui flussi TCP da alcuni punti di presenza (POP). I POP rappresentano una concentrazione di server di memorizzazione nella cache situati in aree metropolitane di grandi dimensioni. Inizialmente, abbiamo eseguito un test BBR su piccola scala in un POP e abbiamo anche eseguito un test POP completo, con tutti i flussi verso i client che eseguono BBR. Per identificare i vantaggi che i clienti potrebbero sperimentare, abbiamo misurato il throughput dai log dei server Web di proxy interni durante il test, nonché l’analisi a livello di socket.

Metriche da valutare

La nostra CDN multi-tenant vede una grande varietà di traffico client. Molti clienti hanno molti oggetti di piccole dimensioni, mentre altri hanno oggetti multi-gigabyte molto più grandi. Pertanto, è fondamentale identificare le metriche di successo in grado di rilevare i miglioramenti effettivi delle prestazioni in diversi modelli di traffico. In particolare, per questa valutazione, abbiamo identificato i tempi di completamento del flusso TCP e del throughput come parametri di successo. Nella Figura 1 viene mostrata una mappa termica delle dimensioni comuni degli oggetti richieste dalla CDN rispetto al tempo impiegato per servirli. La sfumatura di colore indica il numero di richieste in ciascuna categoria. Si tratta di numeri rappresentativi di un piccolo gruppo di server, sufficienti per rilevare solo il comportamento comune.

Figura 1. Mappa termica che mostra le dimensioni comuni degli oggetti.

La mappa termica consente di comprendere i diversi modelli di richiesta. In generale, ottenere un throughput più elevato è il miglior indicatore di guadagno delle prestazioni. Tuttavia, il throughput come misura può essere molto rumoroso, soprattutto nei casi in cui le dimensioni degli oggetti sono ridotte (meno di pochi MB). Pertanto, in base a una valutazione separata delle dimensioni che forniscono la valutazione più affidabile del throughput, utilizziamo solo oggetti di dimensioni superiori a 3 MB per le valutazioni del throughput. Per oggetti di dimensioni inferiori a 3 MB, il monitoraggio dei tempi di completamento del flusso è una misura migliore.

Come primo passo nella nostra valutazione, abbiamo attivato BBR su alcuni server in un POP a Los Angeles e monitorato i tempi di completamento del throughput e del flusso per tutti i flussi TCP. I risultati seguenti esaminano alcuni casi di studio specifici per provider di servizi Internet.

Un provider wireless di grandi dimensioni

La Figura 2 mostra la differenza una volta che BBR è stato attivato.

Figura 2. Impatto del throughput per i clienti di un grande provider wireless quando BBR è stato attivato (test) rispetto ai flussi cubici (controllo). Sinistra: Misurazioni della produttività in due giorni. La linea blu verticale indica quando BBR è stato attivato. Qui vediamo un miglioramento complessivo di circa il 6-8% con BBR. Destra: Un CDF del 5° percentile throughput. I flussi BBR mostrano un miglioramento significativo.

Per questo provider wireless, non appena abbiamo attivato BBR, in media, abbiamo riscontrato un miglioramento del throughput del 6-8%. Nel complesso abbiamo visto tempi di completamento del flusso TCP inferiori. Questo risultato è in accordo con altri report di Spotify, Dropbox e YouTube, in cui si osserva un netto guadagno di throughput nelle reti wireless in cui la perdita di pacchetti è comune, ma ciò non è necessariamente un indicatore di congestione.

Un grande provider di wireline

Successivamente, abbiamo esaminato le prestazioni di un provider wireline di grandi dimensioni. Anche in questo caso abbiamo visto sia il throughput (per oggetti di grandi dimensioni) che il tempo di completamento del flusso (mostrato nella Figura 3). Miglioramenti mediante BBR.

Figura 3. Il tempo medio impiegato per completare un flusso per un provider wireline di grandi dimensioni. I flussi BBR (test) mostrano meno jitter e impiegano meno tempo per completare il trasferimento dei dati. I vantaggi hanno un impatto maggiore per gli oggetti più grandi. Tuttavia, vediamo un jitter simile per file di grandi dimensioni sia per Cubic che per BBR.

I guadagni riportati da questi test mostrano risultati molto promettenti per il traffico lato client.

Poiché questi guadagni sono su una vista aggregata, abbiamo deciso di scavare un po’ più a fondo per verificare se tutti i flussi TCP a POP hanno visto il vantaggio di utilizzare BBR; o se alcuni flussi TCP hanno sofferto, e quali?

All’edge della CDN, vengono eseguiti quattro diversi tipi di sessioni TCP:

  • Pop-to-Client (come mostrato sopra)
  • Pop-to-pop (tra data center)
  • Comunicazione intra-POP (tra le cache dello stesso POP)
  • Pop-to-Origin (pop-to-Origin datacenter del cliente)

Per questo studio, abbiamo preso in considerazione flussi pop-to-client, pop-pop e intra-pop, poiché da edge-to-origin non sono alti come gli altri tre.

Traffico pop-to-pop e intra-pop

È importante valutare anche l’impatto su questi flussi TCP, poiché in molti casi questi flussi bloccano la distribuzione dei client, ad esempio per i contenuti dinamici.

Per il throughput del traffico pop-to-pop e intra-pop, abbiamo assistito a una notevole regressione nelle prestazioni. La Figura 4 mostra l’impatto sul traffico intra-pop e pop-to-pop durante lo stesso periodo di tempo:

Figura 4. Impatto del throughput per il traffico intra-pop e pop-to-pop quando BBR è stato attivato (test) rispetto ai flussi cubici (controllo). Misurazioni della produttività in due giorni. La linea blu verticale indica quando BBR è stato attivato. La produttività è diminuita di circa la metà con BBR.

Tali differenze di prestazioni evidenti tra i flussi verso gli utenti finali e tra i data center non sono state riportate in precedenti risultati. Dobbiamo valutare il motivo per cui questi particolari flussi TCP hanno subito problemi; se si tratta di un artefatto dell’hardware o delle configurazioni sulla nostra CDN; e, in tal caso, quali regolazioni dovrebbero essere modificate.

Da un’ulteriore indagine effettuata utilizzando i registri di accesso ai server Web e le valutazioni dei dati dei socket lato server, è emerso che, in presenza di flussi RTT elevati e bassi, i flussi TCP con RTT molto bassi hanno subito l’uso di BBR. Abbiamo inoltre valutato i casi in cui sono stati trasferiti meno di 0,5 KB di dati e abbiamo riscontrato che nella maggior parte dei casi BBR ha funzionato in modo simile a Cubic.

Sulla base di questi risultati, abbiamo concluso che per i nostri modelli di traffico, è meglio utilizzare Cubic per le comunicazioni intra-pop e pop-to-pop in cui gli RTT e le perdite sono bassi. Per il traffico lato client, vale la pena utilizzare BBR.

Test POP completo

Per valutare i vantaggi in termini di prestazioni di BBR su larga scala, abbiamo eseguito un test POP completo in un POP di Rio de Janeiro per tutto il traffico rivolto ai clienti dalla nostra rete in quel POP. Questo POP ha creato un caso di studio interessante poiché i vincoli di posizione e peering nella regione determinano RTT mediani più elevati sperimentati dai clienti rispetto ad altre regioni.

Figura 5. Miglioramento del throughput utilizzando BBR per il client, IN QUANTO mostra ritrasmissioni elevate (ASN1).

Abbiamo implementato il cambiamento nell’algoritmo di controllo della congestione e monitorato le prestazioni. Viene mostrato un CDF di throughput osservato utilizzando BBR vs. Cubic per i primi due ASE (sistemi autonomi) a Rio. Come illustrato nella Figura 5, uno COME, nel complesso, ha visto il vantaggio di BBR mentre un altro no.

Per analizzare il ragionamento alla base, abbiamo cercato altre metriche TCP raccolte durante il test utilizzando l’utility ss. Una chiara distinzione si osserva nella velocità di ritrasmissione tra questi due ASE. Anche per gli ASE con RTT più elevati, il BBR funziona bene solo per i casi con un elevato numero di ritrasmissioni, in altre parole, per gli ASE con meno perdite Cubic non ha motivo di indietreggiare e funziona meglio di BBR. È tuttavia importante notare che molti dei parametri di TCP Cubic sono stati attentamente sintonizzati sulla nostra CDN.

Successivamente, abbiamo esaminato se tutte le connessioni dell’ASN1 mostrate nella Figura 5 mostravano un miglioramento della produttività. La Figura 6 è un grafico del tempo impiegato (una minore implica una maggiore produttività) da BBR e connessioni cubiche per oggetti di dimensioni diverse. Qui vediamo che BBR ha iniziato a mostrare vantaggi notevoli solo per gli oggetti più grandi, nell’ordine degli MBS. È stata rilevata un’istanza anomala che utilizza BBR, ma non è stato possibile attribuirla a un particolare problema relativo al protocollo di controllo della congestione.

Figura 6. Per gli ASE che mostrano miglioramenti, il vantaggio di BBR è evidente per i flussi a esecuzione prolungata con file di grandi dimensioni.

Perché succede questo?

Questi risultati presentano due dimensioni: Cubica vs. BBR e BBR vs. BBR.

Cubic vs. BBR

BBR è altamente reattivo alle dimensioni del buffer e RTT quando stima la larghezza di banda dei colli di bottiglia. Nel caso di buffer di grandi dimensioni, in cui i middlebox potrebbero costituire una coda, il RTT stimato di BBR aumenta. Poiché non vi è alcuna perdita di pacchetti, Cubic non si ritira in questi casi, in altre parole, il traffico in stile pop-to-pop, e quindi Cubic raggiunge un throughput più elevato. Nel caso di buffer di piccole dimensioni, come i client wireless, il buffer si riempie rapidamente e si traduce in una perdita, pertanto i flussi cubici ritornano indietro e i flussi BBR funzionano meglio.

BBR vs. BBR

In questo scenario, nessun flusso torna indietro quando c’è una perdita. Tuttavia, quando due flussi con RTT diversi competono per una quota di larghezza di banda, il flusso che ha un RTT più elevato ha anche un RTT minimo più grande e quindi un prodotto con ritardo della larghezza di banda più elevato. In questo modo il flusso aumenta i dati in volo a una velocità molto più veloce rispetto al flusso che ha un RTT inferiore. Ciò porta alla riallocazione della larghezza di banda ai flussi in ordine decrescente di RTT e i flussi con RTT più elevati riempiono i buffer più velocemente rispetto ai flussi con RTT di piccole dimensioni.

Riproduzione dei risultati in un’impostazione di laboratorio

Per sviluppare una maggiore comprensione delle interazioni tra i flussi, abbiamo creato un ambiente di test in macchine virtuali che cattura il comportamento osservato in produzione. Abbiamo identificato i modi per simulare diverse classi di traffico in un edge server come segue:

Il ritardo del traffico client è stato impostato a circa 50 ms con perdite comprese tra 0,001 e 0,1 e larghezza di banda dei colli di bottiglia di 50 Mbps. Allo stesso modo, per il pop-to-pop solo la perdita e il ritardo sono stati impostati a ~15 ms e da 0,0001 a 0,01. Per il traffico intra-POP, lasciamo che le macchine virtuali sfruttino al massimo la capacità disponibile. Infine, le simulazioni sono state eseguite utilizzando oggetti di varie dimensioni per catturare la natura multi-tenant del nostro traffico. Eseguiamo tutti e tre i modelli di traffico in parallelo con un arrivo esponenziale dei flussi per catturare una distribuzione di arrivo del flusso in stile poisson. La Figura 7 mostra la configurazione del banco di prova.

L’obiettivo di questo test era riprodurre i problemi riscontrati nei test di produzione, in particolare il calo del throughput per piccoli flussi RTT per il traffico intra-pop e pop-to-pop.

Figura 7. Configurazione del laboratorio mediante le utility KVM, iperf, netem e TC.

Utilizzando questa configurazione, abbiamo eseguito la simulazione centinaia di volte con il traffico in background simulato, sia cubico che BBR, e il tempo necessario per completare i flussi. L’obiettivo del traffico in background è simulare un ambiente di produzione. Molti studi esistenti si sono concentrati sull’esecuzione di alcuni flussi di Cubic e BBR e sulla valutazione dei loro comportamenti. Mentre in questi casi è utile comprendere il comportamento per flusso, esso rappresenta male le complessità di una CDN di grandi volumi. Abbiamo utilizzato il tempo di completamento del flusso lato client come indicatore affidabile poiché per file di piccole dimensioni il throughput può essere rumoroso.

Figura 8. Tempo impiegato dai flussi iperf. Sinistra: Flussi client. Destra: Flussi pop-to-pop. Dimensioni oggetto: 3 MB. BBR ha ottenuto prestazioni migliori rispetto a Cubic per i flussi client simulati.

Abbiamo visto lo schema riapparire anche nel nostro banco di prova. Nella Figura 8, viene illustrato un CDF del tempo impiegato dai flussi BBR e iperf cubici in due scenari: Traffico client e traffico pop-to-pop per file da 3 MB (di medie dimensioni). I flussi BBR non riescono a raggiungere Cubic in un’impostazione a bassa perdita e larghezza di banda elevata. Il traffico client (larghezza di banda ridotta) ha registrato un miglioramento, ossia il tempo impiegato dai flussi BBR è stato inferiore. Tuttavia, i miglioramenti per i file di piccole dimensioni sono marginali. La riproduzione di questi comportamenti nell’ambiente di test ci dà la certezza che siano il risultato dell’interazione tra diversi tipi di flusso. Di conseguenza, qualsiasi implementazione di BBR sulla CDN deve essere consapevole dell’impatto più ampio che può avere su una combinazione di tipi di flusso.

Conclusione

Dalla nostra valutazione, abbiamo osservato che i flussi BBR non funzionano bene in tutti gli scenari. Nello specifico, il traffico all’interno di un data center/punto di presenza (POP) e il traffico tra i data center (POP-to-POP) ha subito un problema quando si utilizza BBR. In alcuni casi estremi, il throughput viene dimezzato. Tuttavia, abbiamo riscontrato un miglioramento del 6-8% del throughput del traffico Pop-to-Client.

In questo post, abbiamo delineato la valutazione di BBR (versione 1) nel contesto della nostra CDN. Abbiamo iniziato con un piccolo test di alcuni server in un singolo POP e abbiamo valutato diverse variabili che ci interessano come grandi provider di contenuti. In un test POP completo su larga scala, abbiamo notato che BBR sarebbe utile soprattutto nei casi in cui le ritrasmissioni sono elevate e suggeriamo che vale la pena utilizzare BBR per i file di grandi dimensioni.

Dove andremo?

Se si attiva il BBR a livello di sistema (tutti i flussi), si rischia di ridurre il throughput del traffico intra-pop e pop-to-pop.

Tuttavia, BBR ha mostrato un potenziale e sta ottenendo buone prestazioni per il traffico lato client. Questo ci motiva ad abilitare in modo selettivo il BBR per i clienti, iniziando potenzialmente con i provider wireless. Inoltre, questi percorsi hanno buffer poco profondi e perdita wireless, una situazione ideale per BBR per prestazioni migliori rispetto ad altri flussi cubici.

Ci auguriamo che questo schema possa chiarire l’uso di BBR presso i grandi provider di contenuti e le sue implicazioni sui diversi tipi di traffico che possono condividere colli di bottiglia. È ora disponibile la versione alpha di BBRv2, che dovrebbe risolvere alcuni di questi problemi. Prevediamo di continuare a valutare le versioni più recenti di BBR e di utilizzare un controller di trasporto intelligente che preleva il giusto controllo della congestione per il giusto tipo di flusso. In futuro condivideremo ulteriori dettagli su questo aspetto.

Grazie al contributo dei vari team dell’organizzazione che ha reso possibile questa analisi!