La larghezza di banda del collo di bottiglia e il tempo di propagazione del round-trip (BBR) sono un algoritmo di controllo della congestione TCP che ha guadagnato un’attenzione significativa sul mercato grazie alla sua capacità di fornire 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 (rete per la distribuzione dei contenuti) di Verizon Media, ora Edgio, che forniscono volumi significativi (più Tbps) di aggiornamenti software e streaming video, e quantificano i vantaggi e l’impatto sul traffico. Ci auguriamo che tale valutazione presso una CDN di grandi dimensioni possa aiutare altri provider di contenuti a scegliere il protocollo di controllo della congestione più adatto al loro traffico.
Sfondo
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 il TCP-Cubic onnipresente, BBR ha un diverso paradigma operativo: 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 di Google qui.
Misurazioni e analisi
Per comprendere il potenziale di BBR nella 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 caching situati in grandi aree metropolitane. 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 dei log dei server Web proxy interni durante il test, nonché l’analisi a livello di socket.
Metriche da valutare
La nostra CDN multi-tenant vede un’ampia varietà di traffico client. Molti clienti hanno molti piccoli oggetti, mentre altri hanno oggetti multi-gigabyte molto più grandi. Pertanto, è fondamentale identificare le metriche di successo che consentano di acquisire i guadagni effettivi delle prestazioni attraverso diversi modelli di traffico. In particolare, per questa valutazione, abbiamo identificato il throughput e i tempi di completamento del flusso TCP 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 a rilevare solo il comportamento comune.
Figura 1. Mappa termica che mostra le dimensioni comuni degli oggetti.
La mappa termica ci fornisce una comprensione dei diversi modelli di richiesta. In generale, ottenere un throughput più elevato è l’indicatore migliore del guadagno di prestazioni. Tuttavia, il throughput come misura può essere molto rumoroso, soprattutto nei casi in cui le dimensioni dell’oggetto sono ridotte (meno di pochi MB). Pertanto, sulla base di una valutazione separata di quali dimensioni 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 metrica migliore.
Come primo passo della nostra valutazione, abbiamo attivato BBR su alcuni server in un POP a Los Angeles e monitorato il throughput e i tempi di completamento del flusso per tutti i flussi TCP. I seguenti risultati esaminano alcuni case study specifici di provider di servizi Internet.
Un provider wireless di grandi dimensioni
La Figura 2 mostra la differenza dopo l’attivazione del BBR.
Figura 2. Impatto sul throughput per i client di un grande provider wireless quando BBR è stato attivato (test) rispetto ai flussi cubici (controllo). Sinistra: Misurazioni della produttività nell’arco di due giorni. La linea blu verticale indica quando è stata attivata la funzione BBR. Qui vediamo un miglioramento complessivo di circa il 6-8% con BBR. Destra: Un CDF del 5o percentile throughput. I flussi BBR mostrano un miglioramento significativo.
Per questo provider wireless, non appena abbiamo abilitato BBR, in media abbiamo notato un miglioramento del throughput del 6-8%. Abbiamo anche registrato tempi di completamento del flusso TCP più bassi. Questo risultato è in accordo con altri report di Spotify, Dropbox e YouTube, in cui si osserva un netto aumento di throughput nelle reti wireless in cui la perdita di pacchetti è comune, ma questo non è necessariamente un indicatore di congestione.
Un grande fornitore di servizi wireline
Successivamente, abbiamo esaminato le prestazioni di un grande provider wireline. Anche in questo caso abbiamo visto miglioramenti sia della produttività (per oggetti di grandi dimensioni) che del tempo di completamento del flusso (mostrato nella Figura 3) utilizzando BBR.
Figura 3. Il tempo medio impiegato per completare un flusso per un grande fornitore di wireline. I flussi BBR (test) mostrano meno jitter e impiegano meno tempo per terminare 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 cubico che per BBR.
I guadagni riportati da questi test mostrano risultati molto promettenti per il traffico lato client.
Poiché questi guadagni sono in una vista aggregata, abbiamo deciso di scavare un po’ più a fondo per verificare se tutti i flussi TCP nel POP vedevano il vantaggio di utilizzare BBR; o se alcuni flussi TCP ne soffrivano, e quali?
All’edge CDN, eseguiamo 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 al data center di origine del cliente)
Per questo studio, sono stati presi in considerazione i flussi pop-to-client, pop-pop e intra-pop, poiché il volume edge-to-origin non è alto 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 sono bloccanti per 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 grande regressione delle prestazioni. La Figura 4 mostra l’impatto sul traffico intra-pop e pop-to-pop durante lo stesso periodo di tempo:
Figura 4. Impatto sul throughput per il traffico intra-pop e pop-to-pop quando BBR è stato attivato (test) rispetto ai flussi cubici (controllo). Misurazioni della produttività nell’arco di due giorni. La linea blu verticale indica quando è stata attivata la funzione BBR. Il throughput è diminuito di circa la metà con BBR.
Tali evidenti differenze di prestazioni tra i flussi agli 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 sofferto; se si tratta di un artefatto di hardware o configurazioni sulla nostra CDN; e in caso affermativo, quali sintonizzazioni dovrebbero essere modificate.
Da ulteriori indagini effettuate utilizzando i registri di accesso al server Web e le valutazioni dei dati socket lato server, è emerso che, in presenza di flussi RTT alti e bassi, i flussi TCP con RTT molto bassi risentivano dell’utilizzo del 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 il BBR ha funzionato in modo simile a quello di Cubic.
Sulla base di questi risultati, abbiamo concluso che per i nostri modelli di traffico, è meglio utilizzare Cubic per comunicazioni intra-pop e pop-to-pop in cui RTT e perdita 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 della nostra rete a contatto con i clienti in quel POP. Questo POP ha fatto un caso di studio interessante, poiché i vincoli di localizzazione e peering nella regione determinano RTT mediani più elevati riscontrati 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 del throughput osservato utilizzando BBR vs. Cubico per i due primi ASE (sistemi autonomi) a Rio. Come si è visto nella figura 5, uno COME, nel complesso, ha visto il vantaggio di BBR, mentre un altro no.
Per esaminare il ragionamento che sta alla base, abbiamo cercato altre metriche TCP raccolte durante il test utilizzando l’utility ss. Una chiara distinzione si riscontra nella velocità di ritrasmissione tra questi due ASE. Anche per gli ASE con RTT più elevati, BBR funziona bene solo per i casi che hanno un numero elevato di ritrasmissioni, in altre parole, per gli ASE con meno perdite Cubic non ha motivo di ritirarsi e funziona meglio di BBR. Tuttavia, è importante notare che molti dei parametri di TCP Cubic sono stati accuratamente sintonizzati sulla nostra CDN.
Successivamente, abbiamo esaminato se tutte le connessioni dall’ASN1 mostrate nella Figura 5 mostravano un miglioramento della produttività. La Figura 6 mostra un grafico del tempo impiegato (inferiore implica una migliore resa) dalle connessioni BBR e cubiche per le diverse dimensioni dell’oggetto. Qui vediamo che BBR ha iniziato a mostrare solo notevoli vantaggi per gli oggetti più grandi, nell’ordine di MBs. È stata rilevata un’istanza anomala utilizzando 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: Cubico vs. BBR e BBR vs. BBR.
Cubico vs. BBR
BBR è altamente reattivo alle dimensioni del buffer e all’RTT quando stima la larghezza di banda del collo di bottiglia. Nel caso di tamponi di grandi dimensioni, in cui i middlebox potrebbero costituire una coda, l’RTT stimato di BBR aumenta. Poiché non vi è alcuna perdita di pacchetti, Cubic non si ritira in questi casi, in altre parole, nel 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 verifica una perdita: In questo modo, i flussi cubici si rimuovono e i flussi BBR funzionano meglio.
Confronto tra BBR e BBR
In questo scenario, nessun flusso si riattiva quando si verifica 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 un ritardo della larghezza di banda più elevato. Pertanto, tale flusso aumenta i dati in entrata a una velocità molto più veloce rispetto al flusso con 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 dei flussi con RTT più piccoli.
Riproduzione dei risultati in un ambiente di laboratorio
Per sviluppare un’ulteriore comprensione delle interazioni tra i flussi, abbiamo creato un ambiente di test nelle 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 ~50 ms con perdite comprese tra 0,001 e 0,1 e larghezza di banda del collo di bottiglia di 50 Mbps. Allo stesso modo, per il pop-to-pop solo perdita e ritardo sono stati impostati a ~15 ms e da 0,0001 a 0,01. Per il traffico intra-pop, lasciamo che le VM estendano 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 letto di prova.
L’obiettivo di questo test era riprodurre i problemi riscontrati nel test di produzione, in particolare il calo di throughput per piccoli flussi RTT per traffico intra-pop e pop-to-pop.
Figura 7. Configurazione del laboratorio utilizzando le utility KVM, iperf, netem e TC.
Utilizzando questa configurazione, abbiamo eseguito la simulazione centinaia di volte con traffico in background simulato, sia cubico che BBR, e abbiamo misurato il tempo necessario per completare i flussi. L’obiettivo del traffico in background è simulare un ambiente simile alla produzione. Molti studi esistenti si sono concentrati sull’esecuzione di alcuni flussi di Cubic e BBR e sulla valutazione dei loro comportamenti. Anche se in questi casi è utile comprendere il comportamento per flusso, rappresenta in modo inadeguato le complessità di una CDN di grandi dimensioni e con volumi elevati. Abbiamo utilizzato il tempo di completamento del flusso sul 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. Dimensione oggetto: 3 MB. BBR ha funzionato meglio di Cubic per flussi client simulati.
Abbiamo visto lo schema riapparire anche nel nostro banco di prova. Nella Figura 8, viene mostrato un CDF del tempo impiegato dai flussi BBR e iperf cubici in due scenari: Traffico client e traffico pop-to-pop per i file di 3 MB (di medie dimensioni). I flussi BBR non riescono a raggiungere il valore cubico in una configurazione a bassa perdita e larghezza di banda elevata. Il traffico client (larghezza di banda bassa) ha registrato un miglioramento, ovvero il tempo impiegato dai flussi BBR è stato inferiore. Tuttavia, il miglioramento per i fascicoli di piccole dimensioni è marginale. 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. In particolare, il traffico all’interno di un data center/punto di presenza (POP) e il traffico tra data center (POP) subiscono quando si utilizza BBR. In alcuni casi estremi, la produttività viene dimezzata. Tuttavia, abbiamo riscontrato un miglioramento del 6-8% nel 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 unico POP e abbiamo valutato diverse variabili che ci interessano in qualità di grande fornitore di contenuti. In un test POP completo su larga scala, abbiamo notato che il BBR sarebbe utile nella maggior parte dei casi per gli ASE in cui le ritrasmissioni sono elevate e suggeriamo che vale la pena utilizzare il BBR per i file di grandi dimensioni.
Dove andremo da qui?
Se si abilita 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 potenziale e sta funzionando bene per il traffico lato client. Questo ci spinge ad attivare selettivamente BBR per i clienti, iniziando potenzialmente dai 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 porti chiarezza sull’uso del BBR presso i grandi fornitori di contenuti e sulle sue implicazioni sui diversi tipi di traffico che possono condividere colli di bottiglia. La versione alpha di BBRv2 è ora disponibile, 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 in merito.
Grazie al contributo dei vari team dell’organizzazione che ha reso possibile questa analisi!
