Home Articoli tecnici Miglioramento delle prestazioni della rete con la regolazione del controllo dinamico della congestione
Applications

Miglioramento delle prestazioni della rete con la regolazione del controllo dinamico della congestione

About The Author

Outline

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, sono stati sviluppati altri CCA, come la larghezza di banda del collo di bottiglia, il tempo di propagazione del viaggio di andata e ritorno (TCP BBR) e CUBIC. Mentre TCP BBR e CUBIC mirano a evitare la congestione, comprendere la loro efficacia è stata una missione costante per i nostri team di ricerca e ingegneria.

TCP BBR mira a ottenere un throughput più elevato utilizzando il ritardo dei pacchetti come indicatore invece della perdita dei pacchetti. Tuttavia, la nostra precedente ricerca ha riferito 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) presenta pochi o nessun vantaggio<. Inoltre, abbiamo osservato che le prestazioni del BBR per i flussi con un tempo di andata e ritorno (RTT) basso e le ritrasmissioni basse erano peggiori di quelle DI CUBIC. Infine, i vantaggi del BBR sono stati riscontrati solo per il traffico rivolto ai clienti, mentre le connessioni back-Office (RTT basso e ritrasmissioni trascurabili) hanno funzionato meglio con CUBIC.

Edgecast, ora Edgio, è una CDN multi-tenant globale che distribuisce traffico Web a molti clienti di streaming video (VOD e live) di grandi dimensioni. Dato che le sintonizzazioni di 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 deterioramento delle prestazioni in alcuni scenari, abbiamo implementato un meccanismo per rilevare i casi in cui BBR fornisce prestazioni migliori e può abilitarle dinamicamente per tutti i clienti CDN. Il risultato è una nuova funzione di regolazione del controllo della congestione dinamica 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 regolazione del controllo dinamico della congestione si trova in cima alla nostra raccolta dati socket su larga scala, che esporta i dati sulle prestazioni del socket TCP (xTCP) da tutte le cache edge. In particolare, estrae informazioni dalla struttura tcp_INFO del kernel Linux tramite NetLink e le trasmette tramite Kafka in un cluster ClickHouse. Disporre di questi dati sulle prestazioni del 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 l’aumento delle prestazioni tramite 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 il gran 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, abbiamo in programma di aprire xTCP presto.

Nella figura seguente viene mostrata la panoramica del sistema. I dati xTCP vengono raccolti su larga scala da tutte le nostre cache edge trasmesse 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 inferiori a ciascun pop edge.

Figura 1. Panoramica della raccolta dati mediante un push di configurazione xTCP e BBR.

Anche se vogliamo mantenere la natura dinamica del nostro flusso di lavoro, dobbiamo anche selezionare prefissi costantemente con prestazioni inferiori a ogni punto di presenza (POP) per evitare flip-flopping tra CUBIC e BBR per brevi periodi. Inoltre, come già osservato, viene attivato in modo selettivo BBR per le richieste in cui la dimensione del file è superiore a 100 KB. Un flusso CUBICO ottimizzato funziona meglio 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 gruppo di prestazioni del 20° percentile inferiore?
  • Velocità di deflessione: Con quale frequenza il prefisso viene visualizzato e scompare dal gruppo di prestazioni del 20° percentile inferiore, ossia un 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 ogni pop edge potrebbe essere compreso tra le centinaia, abbiamo osservato che le prestazioni dei prefissi rimangono relativamente coerenti. Gli stessi prefissi vengono selezionati regolarmente e le nuove aggiunte in ogni round (come mostrato nella figura seguente dal pop di Chicago) sono pochissime.

Figura 2. Il numero di nuovi prefissi selezionati per ogni round di generazione della configurazione è basso.

Se presenti, vengono selezionati nuovi prefissi per abilitare BBR e viene generata una configurazione, eseguita attraverso una fase di convalida e inviata alle cache edge a livello globale.

Miglioramenti delle prestazioni

Siamo lieti di comunicare che l’abilitazione di BBR in tutto il mondo ha mostrato notevoli miglioramenti nelle prestazioni. Una metrica chiave tracciata dai dati del socket xTCP è la velocità di consegna riportata in TCP_INFO. Dal momento che consentiamo dinamicamente BBR per i prefissi con prestazioni inferiori, ci aspettiamo un miglioramento della nostra velocità di consegna del percentile (nel peggiore dei casi).

La figura seguente mostra il miglioramento della velocità 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 seguente, mostriamo un notevole miglioramento (~2x) nella velocità di consegna del percentile 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 rilevate dal client. Tuttavia, l’indicatore delle prestazioni più preciso è il throughput visualizzato nei registri di accesso HTTP per la connessione client, ovvero, goodput.

Misuriamo il goodput da un server cache edge. Come mostrato nella figura seguente, la modifica ha comportato un aumento del goodput. Nel complesso, il 10° percentile è aumentato del 12%.

Figura 5. Il 10° percentile goodput è aumentato del 12%.

Un ringraziamento speciale al team di sviluppo BBR di Google per il loro straordinario lavoro su BBRv1 e il loro continuo impegno su BBRv2. Attendiamo con impazienza BBRv2 e a breve continueremo a presentare 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 di Edgecast per aver supportato questo cambiamento durante lo sviluppo, il test e l’implementazione. Il team di progettazione di Edgio desidera ringraziare in particolare Dave Seddon per aver contribuito allo sviluppo dello strumento xTCP che ha alimentato gran parte dell’analisi.

Grazie all’ottimizzazione dinamica del controllo della congestione, i clienti di Edgio ora ottengono automaticamente miglioramenti prestazionali per i loro clienti con prestazioni inferiori e migliorano le performance dei profitti, con conseguente distribuzione più rapida del web e una riduzione dei rebuffers per lo streaming video.