L’algoritmo di controllo della congestione (CCA) TCP (Transmission Control Protocol) regola la quantità di dati da inviare tra client e server per massimizzare l’utilizzo della larghezza di banda disponibile ed evitare la congestione. Fin dalla sua nascita, altre CCA sono state sviluppate fin dal suo inizio, come la larghezza di banda del collo di bottiglia, il tempo di propagazione del round-trip (TCP BBR) e IL CUBIC. Mentre TCP BBR e CUBIC mirano a evitare la congestione, la loro efficacia è stata una missione costante per i nostri team di progettazione e ricerca.
TCP BBR mira a ottenere un throughput più elevato utilizzando il ritardo dei pacchetti come indicatore invece della perdita di pacchetti. Tuttavia, la nostra precedente ricerca ha riportato che BBR funziona male in tutti i casi. In particolare, la nostra valutazione ha concluso che il throughput per i file di piccole dimensioni (<100 KB) non ha comportato alcun vantaggio. Inoltre, abbiamo osservato che le prestazioni BBR per i flussi con un tempo di round-trip basso (RTT) e ritrasmissioni basse erano peggiori di quelle DI CUBIC. Infine, i vantaggi di BBR sono stati osservati solo per il traffico diretto ai client, mentre le connessioni di back-Office (RTT basso e ritrasmissioni trascurabili) hanno funzionato meglio con CUBIC.
Edgecast, ora Edgio, è una CDN globale multi-tenant che distribuisce traffico web per molti grandi clienti di streaming video (VOD e live). Dato che le ottimizzazioni del controllo della congestione che utilizzano BBR per un cliente possono influire negativamente sulle prestazioni di un altro cliente e un’abilitazione globale potrebbe causare un peggioramento delle prestazioni in alcuni scenari, abbiamo implementato un meccanismo per rilevare i casi in cui BBR fornisce prestazioni migliori e può attivarle dinamicamente per tutti i clienti CDN. Il risultato è una nuova funzione di regolazione del controllo dinamico della congestione che abbiamo messo a disposizione di tutti i nostri clienti.
Approfondimenti sulla metodologia
Forse l’input più importante per un sistema così dinamico sono i dati che lo alimentano. Il nostro meccanismo di sintonizzazione del controllo dinamico della congestione si trova in cima alla nostra raccolta di dati socket su larga scala, che esporta i dati sulle prestazioni del socket TCP (xTCP) da tutte le cache edge. Nello specifico, estrae informazioni dalla struttura tcp_info del kernel Linux tramite NetLink e le trasmette via Kafka in un cluster ClickHouse. Disporre di questi dati sulle prestazioni dei socket su larga scala ci consente di monitorare le prestazioni delle connessioni ai nostri server cache con granularità molto elevata. XTCP si è dimostrato uno strumento potente per molte ottimizzazioni CDN. Ad esempio, di recente abbiamo attivato la finestra di congestione iniziale IPv6 e monitorato aumenta le prestazioni utilizzando xTCP.
XTCP è simile al lavoro svolto dallo strumento tcp-info di Google Measurement Lab (M-Lab) con differenze significative derivanti dalle ottimizzazioni necessarie per gestire l’elevato numero di socket visti dalle nostre cache edge (rispetto ai server M-Lab) e la capacità di esportare i dati in formato protobuf. Restate sintonizzati, prevediamo di aprire a breve xTCP open source.
Nella figura seguente viene mostrata la panoramica del nostro sistema. I dati xTCP vengono raccolti su vasta scala da tutte le nostre cache edge in streaming in Kafka. I dati xTCP vengono quindi raccolti in un cluster ClickHouse, che alimenta l’analisi dei dati di rete, incluso il controller BBR, che rileva i prefissi con prestazioni insufficienti in ogni edge pop.
Figura 1. Panoramica della raccolta dati utilizzando un push di configurazione xTCP e BBR.
Pur volendo mantenere la natura dinamica del flusso di lavoro, dobbiamo anche selezionare prefissi costantemente sottoperformanti in ogni punto di presenza edge (POP) per evitare il flip-flopping tra CUBIC e BBR in brevi periodi. Inoltre, come già detto, viene attivato selettivamente BBR per le richieste in cui la dimensione del file è superiore a 100 KB. Un flusso CUBICO ottimizzato offre prestazioni migliori per i file di piccole dimensioni.
Il controller BBR utilizza due metriche per valutare lo stato di ogni prefisso client osservato:
- Ciclo di lavoro: Per quanto tempo è stato un prefisso (/24 o /56) nel 20° percentile gruppo di prestazioni inferiore?
- Tasso di deflazione: Con quale frequenza il prefisso viene visualizzato e scompare dal gruppo di prestazioni del 20° percentile inferiore, ossia il cambiamento di stato?
L’algoritmo rileva quindi costantemente i prefissi con prestazioni peggiori nelle ultime ore. Questo rilevamento viene eseguito ogni 5 minuti. Mentre il numero totale di prefissi selezionati per edge pop potrebbe essere di centinaia, abbiamo osservato che le prestazioni dei prefissi rimangono relativamente coerenti. Gli stessi prefissi vengono selezionati regolarmente e le nuove aggiunte in ogni turno (come mostrato nella figura seguente del pop di Chicago) sono molto poche.
Figura 2. Il numero di nuovi prefissi selezionati per ciclo di generazione della configurazione è basso.
Se presenti, vengono selezionati nuovi prefissi per abilitare BBR e viene generata una configurazione, passata attraverso una fase di convalida e inviata alle nostre cache edge a livello globale.
Guadagni prestazionali
Siamo lieti di annunciare che l’attivazione di BBR a livello mondiale ha mostrato notevoli miglioramenti delle prestazioni. Una metrica chiave tracciata dai dati del socket xTCP è la velocità di consegna riportata in TCP_INFO. Poiché abilitiamo dinamicamente il BBR per i prefissi con prestazioni più basse, ci aspettiamo un miglioramento della nostra velocità di consegna in percentile inferiore (nel peggiore dei casi).
La figura seguente mostra il miglioramento del tasso di consegna del 5° e 10° percentile al nostro POP di Los Angeles non appena il cambio BBR è stato attivato.
Figura 3. Sono stati osservati miglioramenti nei tassi di consegna del 5° e 10° percentile in seguito alla modifica del BBR.
Allo stesso modo, nella figura che segue, mostriamo un notevole miglioramento (~2x) della percentuale di consegna inferiore per un grande ISP residenziale negli Stati Uniti non appena abbiamo attivato dinamicamente BBR in tutti i nostri POP nordamericani.
Figura 4. Sono stati osservati miglioramenti per un grande ISP residenziale dopo aver attivato dinamicamente BBR.
La velocità di consegna estratta da TCP-info fornisce una buona stima delle prestazioni osservate dal client. Tuttavia, l’indicatore di prestazioni più preciso è il throughput visualizzato nei log di accesso HTTP per la connessione client, ovvero, goodput.
Il goodput viene misurato da un server cache edge. Come mostrato nella figura seguente, la modifica ha comportato un aumento dell’avviamento. Nel complesso, il goodput del decimo percentile è aumentato del 12%.
Figura 5. Il decimo percentile goodput è aumentato del 12%.
Un ringraziamento speciale al team di sviluppo BBR di Google per l’incredibile lavoro svolto su BBRv1 e il continuo impegno profuso su BBRv2. Attendiamo con impazienza BBRv2 e continueremo a introdurre a breve modifiche rilevanti alla nostra piattaforma. Complimenti a Sergio Ruiz, Joseph Korkames, Joe Lahoud, Juan Bran, Daniel Lockhart, Ben Lovett, Colin Rasor, Mohnish Lad, Muhammad Bashir, Zach Jones e Dave Andrews presso Edgecast per aver sostenuto questo cambiamento durante lo sviluppo, il test e l’implementazione. Il team tecnico Edgio ringrazia in particolare Dave Seddon per aver contribuito allo sviluppo dello strumento xTCP che ha alimentato gran parte dell’analisi.
Grazie all’ottimizzazione del controllo dinamico della congestione, i clienti Edgio ottengono automaticamente miglioramenti delle performance per i clienti che non hanno raggiunto le prestazioni migliori e migliorano le performance di base, con conseguente delivery Web più veloce e una riduzione dei rebuffer per lo streaming video .
