Bufferbloat: perché una connessione veloce diventa lenta e come risolvere

Avere a disposizione una connessione Internet da 1 Gbps non significa necessariamente avere una rete reattiva. È possibile scaricare centinaia di megabit al secondo e, nello stesso momento, vedere una videoconferenza bloccarsi, una sessione desktop remoto rispondere con ritardo oppure il ping di un gioco online passare improvvisamente da 5 ms a diverse centinaia di millisecondi.

Il problema, in casi come questi, non è la banda disponibile. Potrebbe invece chiamarsi bufferbloat: un fenomeno poco conosciuto “dalle masse” ma capace di trasformare una connessione apparentemente eccellente in una rete poco reattiva quando le attività in download o in upload utilizzano intensamente il collegamento.

Il termine descrive la latenza aggiuntiva provocata dall’accumulo eccessivo di pacchetti nei buffer dei dispositivi di rete: router, modem e altri apparati cercano di non perdere dati mettendoli temporaneamente in coda. Quando però tali code diventano troppo profonde, i pacchetti non vengono persi ma possono aspettare decine, centinaia o perfino migliaia di millisecondi prima di essere trasmessi. Un buffer molto grande può evitare la perdita di pacchetti e contemporaneamente peggiorare drasticamente l’esperienza dell’utente.

Il problema è sufficientemente importante da essere affrontato anche dalla IETF. La RFC 7567, pubblicata come Best Current Practice 197, raccomanda esplicitamente l’uso di tecniche di Active Queue Management (AQM) per controllare le code nei dispositivi di rete e ridurre la latenza.

Che cos’è il bufferbloat

Internet funziona trasferendo pacchetti tra dispositivi che possono operare a velocità differenti. Basti immaginare un router domestico che riceve dati da un computer attraverso Ethernet a 1 o 2,5 Gbps ma deve poi inviarli su una connessione Internet con un upload da 20 Mbps. Se il PC produce dati più velocemente di quanto il collegamento WAN riesca a trasmetterli, qualcosa deve pur succedere ai pacchetti in eccesso.

Il router potrebbe eliminarli oppure conservarli temporaneamente in memoria. La seconda soluzione sembra intuitivamente migliore: perché buttare via informazioni che possono essere semplicemente trasmesse qualche istante più tardi? È il ragionamento che, per molto tempo, ha spinto progettisti di hardware e software a utilizzare buffer sempre più capienti.

Il problema nasce quando i tempi tendono ad allungarsi: IETF osserva che l’accodamento è assolutamente normale in una rete a commutazione di pacchetto: serve ad assorbire brevi picchi di traffico. Code eccessive, tuttavia, introducono ritardi che possono compromettere pesantemente le applicazioni interattive.

Così, il fenomeno del bufferbloat può essere descritto come la latenza indesiderata generata da apparati di rete che mantengono troppi dati nei rispettivi buffer.

Perché l’upload è particolarmente pericoloso: spieghiamolo con un esempio

Supponiamo di avere un collegamento FTTC (Fiber-to-the-Cab) o una connessione radio con 200 Mbps in download e 20 Mbps in upload. Immaginiamo poi, soltanto come esempio teorico, che lungo il collo di bottiglia possano accumularsi circa 10 MB di dati.

Dieci megabyte equivalgono grossomodo a 80 megabit. Su un collegamento che può smaltire soltanto 20 Mbps (è questo il valore di upload nel nostro esempio), svuotare quella quantità di dati richiede 80 Mbit / 20 Mbps = circa 4 secondi.

Non significa che ogni router utilizzi buffer da 10 MB né che il ritardo raggiunga necessariamente 4 secondi. L’esempio serve soltanto a mostrare un principio importante: la dimensione del buffer deve essere rapportata alla velocità del collo di bottiglia.

Una quantità di memoria apparentemente innocua su una linea a 1 Gbps può rappresentare una coda gigantesca su un upload da 10 o 20 Mbps. Ed è proprio per questo motivo che il bufferbloat risulta spesso particolarmente evidente durante gli upload.

Un backup cloud, la sincronizzazione di OneDrive, Google Drive o Dropbox, l’invio di un grande allegato, un sistema di videosorveglianza che trasferisce dati verso Internet oppure un client BitTorrent possono saturare l’upload molto rapidamente tanto che all’improvviso, anche semplici richieste web appaiono lente.

Perché anche il download può far schizzare il ping

Come abbiamo spiegato al paragrafo precedente, è intuitivo comprendere il bufferbloat in upload perché la coda può formarsi direttamente sul router domestico.

Nel caso del download, il punto di congestione può trovarsi nel modem, nel router, nell’ONT, nell’infrastruttura dell’operatore oppure in qualche altro tratto della rete. Di conseguenza, controllare soltanto le code in uscita dal proprio router non garantisce automaticamente il controllo delle code presenti a monte.

È uno dei motivi per cui le soluzioni di Smart Queue Management (SQM) non si limitano a “dare priorità al gaming”, ma cercano di creare artificialmente un collo di bottiglia controllabile dal router.

Se, ad esempio, una connessione raggiunge realmente 500 Mbps, il router può limitare volontariamente il traffico a un valore leggermente inferiore, per esempio 470-480 Mbps. Questa tecnica, chiamata traffic shaping, fa sì che il punto di congestione si formi nel router stesso: lì le code possono essere controllate con algoritmi evoluti, invece di lasciare che i pacchetti si accumulino nel modem o nella rete dell’operatore, dove l’utente non ha alcun controllo sulla loro gestione.

Si sacrifica così una piccola quantità di throughput massimo in cambio di una riduzione – spesso davvero significativa – della latenza sotto carico.

I “numeri” che uno speed test tradizionale può nascondere

Misurare soltanto Mbps in download e upload non basta per giudicare una connessione Internet. Uno speed test tradizionale potrebbe restituire valori incoraggianti in download, upload e in termini di latenza (ping in millisecondi).

Il valore di ping, però, è spesso interpretato senza chiedersi cosa accade alla latenza mentre la connessione è sotto carico. Supponiamo che durante un trasferimento intenso il ping passi da 9 a 180 ms. Il collegamento ultraboardband continua magari a trasferire 930 Mbps, quindi dal punto di vista della banda sembra eccellente. Dal punto di vista dell’interattività, invece, la situazione è completamente diversa.

È quindi utile distinguere almeno tre grandezze:

• latenza a riposo, quando la linea è quasi inutilizzata;
• latenza sotto download, mentre il collegamento riceve dati alla massima velocità;
• latenza sotto upload, quando l’upstream è saturo.

Le prove svolte da Waveform Bufferbloat Test misurano la latenza sia a linea scarica che durante download e upload, offrendo quindi un resoconto molto più affidabile sulle performance della connessione anche in condizioni di carico.

Come verificare il bufferbloat anche da Windows

Un controllo molto semplice può essere effettuato anche senza installare programmi e senza avvalersi di strumenti web di terze parti.

Da Windows si può aprire il Prompt dei comandi (cmd) e digitare, ad esempio:

ping -t 1.1.1.1

L’IP pubblico 1.1.1.1 corrisponde ai server o resolver DNS di Cloudflare. In alternativa si può specificare un altro host stabile e geograficamente vicino.

Conviene osservare per qualche secondo il tempo di risposta quando la connessione è inutilizzata. Se normalmente si ottengono, per esempio, 15-20 ms, quello rappresenta un riferimento indicativo.

A questo punto si può avviare un trasferimento capace di saturare il download e osservare nuovamente il ping. Lo stesso esperimento va ripetuto saturando l’upload.

Se da 15 ms si passa, per esempio, a 20-30 ms, la gestione delle code è probabilmente buona. Se il valore sale stabilmente verso 100, 300, 500 ms o oltre, esiste invece un forte indizio di code eccessive.

Ovviamente questo tipo di approccio non costituisce da solo una diagnosi definitiva: WiFi congestionato, interferenze radio, perdita di pacchetti, problemi lato provider e variazioni del percorso Internet possono alterare il risultato. Il confronto tra rete scarica e stessa rete sotto carico resta però estremamente istruttivo.

Prima di avviare qualunque test “serio”, conviene eliminare una variabile importante: il WiFi. Una rete wireless introduce infatti ritrasmissioni, contesa del mezzo, variazioni della modulazione, code nel driver e nell’access point, interferenze e altri client che condividono il tempo radio. Va quindi preferito il collegamento Ethernet, via cavo.

Ping alto e bufferbloat sono due problemi diversi

È importante non confondere il bufferbloat con una connessione che presenta semplicemente una latenza elevata.

Una connessione satellitare, ad esempio, può avere per sua natura una latenza superiore rispetto a una FTTH (Fiber-to-the-Home). Il parametro spesso usato per misurarla è RTT (Round Trip Time), cioè il tempo necessario affinché un pacchetto parta dal dispositivo, raggiunga la destinazione e torni indietro con la risposta. Nelle connessioni satellitari il percorso fisico del segnale è molto più lungo rispetto a quello di una rete in fibra: di conseguenza l’RTT può essere più elevato anche quando la rete funziona perfettamente e non presenta alcun problema di bufferbloat.

Il bufferbloat misura invece soprattutto quanto aumenta la latenza quando si formano code durante il traffico intenso. Inoltre, può aumentare non soltanto il valore medio della latenza ma anche il jitter, cioè la sua variabilità nel tempo.

Per un download tradizionale, ricevere un pacchetto dopo 20 o 100 ms cambia relativamente poco. Per audio, video e giochi online la situazione è differente.

Se una serie di pacchetti arrivano rispettivamente dopo 20, 22, 19, 180, 25 e 210 ms, l’applicazione deve compensare variazioni enormi. Una chiamata VoIP può produrre audio irregolare; una videoconferenza può mostrare scatti; un gioco online percepisce il fenomeno come lag.

È quindi possibile avere moltissima banda disponibile e, contemporaneamente, una qualità pessima per le applicazioni in tempo reale.

Cosa fare su Windows: prima di tutto capire cosa non può il sistema Microsoft

Online circolano molte “ottimizzazioni anti-bufferbloat” basate su quattro o cinque comandi netsh da impartire al prompt dei comandi di Windows. Alcune possono effettivamente trasformare un voto F in A in un test come Waveform Bufferbloat Test.

Va però fatto un appunto fondamentale: modificare il comportamento TCP di un singolo PC non equivale a correggere la coda del router.

Windows può ridurre quanto aggressivamente un determinato trasferimento utilizza la connessione; limitare un programma; modificare alcuni aspetti dello stack TCP; aiutare a diagnosticare il problema. Non può però decidere come il router accodi il traffico prodotto contemporaneamente da un NAS, uno smartphone, una console e altri computer.

È un argomento che merita particolare attenzione perché spiega molti risultati apparentemente miracolosi pubblicati online.

I quattro comandi che promettono di trasformare F in A nelle valutazioni sul bufferbloat

Una guida molto diffusa propone i seguenti comandi Windows:

netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global ecncapability=enabled
netsh int tcp set global timestamps=disabled
netsh int tcp set global rsc=disabled

È perfettamente possibile che, dopo queste modifiche, un test restituisca una latenza inferiore e un giudizio particolarmente incoraggiante.

autotuninglevel=disabled Windows utilizza il TCP Receive Window Auto-Tuning (Livello regolazione automatica finestra ricezione) per adattare dinamicamente la finestra di ricezione TCP. Il comando proposto mantiene invece la finestra di ricezione molto più vincolata.

Impostando il parametro su normal, che è il valore di default, Windows può aumentare la finestra di ricezione in funzione delle caratteristiche della connessione. Microsoft raccomanda proprio normal quando si vuole evitare che una finestra TCP troppo piccola limiti il throughput, soprattutto sulle reti con elevato prodotto banda-latenza.

Se disabilitiamo l’auto-tuning, un trasferimento TCP in ricezione può non riuscire più a sfruttare la quantità di banda disponibile sul collegamento: il ping si riduce (risultato sperato) ma i Mbps, purtroppo, diminuiscono anch’essi.

Il test da fare per dimostrare che il miglioramento è fumo negli occhi

Con Windows regolato sulle impostazioni predefinite (netsh int tcp set global autotuninglevel=normal) eseguiamo il test e annotiamo velocità, latenza senza carichi o in idle, latenza durante download, latenza durante upload.

Dopo aver digitato netsh int tcp set global autotuninglevel=disabled, ripetiamo esattamente la stessa prova. Se il voto migliora molto ma il throughput cala sensibilmente, abbiamo individuato il motivo.

Per l’uso normale Microsoft suggerisce di mantenere l’auto-tuning su normal (netsh int tcp set global autotuninglevel=normal): nelle sue linee guida sul troubleshooting TCP indica esplicitamente questa configurazione e raccomanda di lasciare attive anche le principali ottimizzazioni dell’interfaccia di rete, salvo problemi specifici di compatibilità.

C’è poi un esperimento ancora più interessante che si può mettere in campo: sul PC A supponiamo di aver impostato autotuninglevel=disabled, ottenendo uno “sfavillante” voto A. Lasciamo il PC A quasi inattivo e dal PC B o da un NAS saturiamo l’upload.

Sul PC A continuiamo con un ping -t 1.1.1.1: se la latenza torna a 200 o 400 ms, abbiamo la dimostrazione che la configurazione Windows non può ovviamente nulla sul funzionamento della coda lato router. Un router configurato correttamente con SQM, invece, gestisce il traffico complessivo della rete.

ECN, timestamp e RSC: cosa cambiano in Windows

Gli altri tre comandi spesso suggeriti insieme alla disattivazione del TCP Auto-Tuning hanno un impatto molto più limitato sul bufferbloat.

Un’istruzione come netsh int tcp set global ecncapability=enabled abilita ECN, Explicit Congestion Notification, cioè la possibilità di segnalare una congestione (indicata come Funzionalità ECN, in italiano) marcando i pacchetti invece di affidarsi soltanto alla loro perdita: è una funzione tecnicamente utile, soprattutto quando lavora insieme ad algoritmi AQM sul router, ma non riduce da sola la profondità delle code.

Il comando netsh int tcp set global timestamps=disabled disabilita invece i timestamp TCP, impiegati anche per alcune misurazioni temporali e meccanismi di protezione del protocollo; non esiste però un rapporto diretto tra timestamp attivi e bufferbloat, quindi modificarli difficilmente risolve il problema.

Infine, netsh int tcp set global rsc=disabled disattiva Receive Segment Coalescing, una tecnica (in italiano è Stato unione segmenti ricezione) che aggrega segmenti ricevuti per ridurre il carico di elaborazione sulla CPU. RSC può incidere sul comportamento locale dello stack di rete e su benchmark molto sensibili alla latenza, ma non controlla la coda WAN del router.

ECN può collaborare con una buona gestione della congestione, mentre timestamp e RSC sono soprattutto parametri dell’endpoint: nessuno dei tre sostituisce SQM, CAKE o FQ-CoDel sul dispositivo che gestisce il collo di bottiglia (ne parliamo più avanti).

La vera soluzione: controllare la coda nel punto del collo di bottiglia

Per gestire correttamente il bufferbloat bisogna fare in modo che la coda principale si trovi in un dispositivo che possiamo controllare. Supponiamo che l’upload reale sia 100 Mbps: se il router invia dati a 100 Mbps esatti verso un ONT o verso il modem dell’operatore, basta una minima variazione della capacità reale perché i pacchetti inizino ad accumularsi nel dispositivo a valle. Il nostro router non vede direttamente quella coda e non può gestirla.

Se invece configuriamo sul router uno shaper a 95 Mbps, abbiamo creato deliberatamente un collo di bottiglia leggermente più lento prima del dispositivo dell’operatore.

Nella gestione di tutto il traffico da e verso la rete locale, la coda può quindi formarsi adesso sul nostro router. Se quella coda è gestita con algoritmi come CAKE o FQ-CoDel, il router non si limita ad accumulare pacchetti in ordine di arrivo: controlla quanto tempo restano in attesa, separa i flussi di traffico e interviene prima che la coda diventi troppo profonda. In questo modo un grande download o un upload imponente possono continuare a usare molta banda senza costringere pacchetti più sensibili alla latenza, come quelli di DNS, VoIP, gaming o desktop remoto, ad aspettare centinaia di millisecondi.

È questo il motivo per cui una buona configurazione anti-bufferbloat può sacrificare qualche punto percentuale di throughput: non è banda “sprecata”: è il margine necessario per mantenere il controllo della coda.

Illudersi che bastino quattro comandi netsh int tcp in Windows per risolvere il problema del bufferbloat suona quasi irrispettoso nei conferonti del lavoro svolto, ad esempio, da figure come Dave Täht, ingegnere che in silenzio ha fatto funzionare meglio le reti con il QoS.

SQM, CAKE e FQ-CoDel: cosa serve davvero sul router

La soluzione più efficace al bufferbloat consiste nel controllare la coda nel punto in cui la connessione raggiunge il proprio limite. SQM, Smart Queue Management, citato già un paio di volte nel corso del nostro articolo, fa proprio questo: combina limitazione della velocità, gestione attiva delle code e distribuzione più equa della banda tra i flussi.

Un firmware come OpenWrt lo rende particolarmente accessibile e propone CAKE come soluzione preferenziale, mentre FQ-CoDel è un’alternativa meno completa ma generalmente più leggera per la CPU.

FQ-CoDel separa i diversi flussi di traffico e controlla quanto tempo i pacchetti rimangono in coda: un grosso download può continuare a utilizzare gran parte della connessione senza costringere una richiesta DNS, una videoconferenza o una sessione SSH ad aspettare dietro migliaia dei suoi pacchetti. CAKE aggiunge nello stesso sistema shaping, isolamento tra host e flussi e compensazione dell’overhead della linea.

La prima cosa da provare: ridurre leggermente la banda sul router

Prima ancora di installare OpenWrt, vale la pena controllare se il router dispone di una funzione chiamata QoS (Quality-of-Service), Traffic Shaping, Smart Queue, Bandwidth Control o simile.

Supponiamo che una connessione misuri realmente in download qualcosa come 940 Mbps e in upload: 290 Mbps. Configurare sul router un limite, ad esempio, di 900 Mbps in download e 275 Mbps in upload può già produrre un miglioramento enorme.

Limitando leggermente la velocità, il router può diventare il collo di bottiglia prima dell’ONT, del modem o degli apparati dell’ISP. I pacchetti tendono quindi ad accumularsi nel dispositivo che possiamo controllare anziché in una coda esterna.

Un semplice rate limiter può essere sufficiente se il problema principale consiste nello spostare il collo di bottiglia, ma non offre necessariamente la stessa qualità di CAKE o FQ-CoDel. Se dietro al limite rimane una grande coda FIFO (first-in, first-out), sotto forte carico può ancora accumularsi latenza.

Ridurre la banda del 5-10% tramite QoS è un’ottima prima prova e, su alcuni router, può persino risolvere praticamente il problema. Se il ping continua invece ad aumentare molto durante download o upload, serve una gestione delle code più evoluta.

Non bisogna impostare automaticamente il 90% della velocità nominale del contratto: prima si misura la velocità reale, preferibilmente più volte e via Ethernet. Si parte quindi con un valore prudente, per esempio l’85-90%, e si aumenta gradualmente.

OpenWrt non è l’unica possibilità

OpenWrt è interessante perché permette di utilizzare CAKE e FQ-CoDel anche su molti router consumer, ma esistono diverse alternative.

OPNsense, ad esempio, dispone di una configurazione specificamente documentata per combattere il bufferbloat con FQ-CoDel. Permette di creare pipe separate per download e upload, impostarne la larghezza di banda e lasciare all’algoritmo il compito di distribuire i flussi e mantenere basso il tempo di permanenza in coda.

Anche UniFi offre sui propri gateway la funzione Smart Queues: si impostano download e upload disponibili e il gateway limita opportunamente il traffico per evitare che alcuni client monopolizzino il collegamento. Ubiquiti la presenta esplicitamente come funzione contro il bufferbloat, anche se la consiglia soprattutto sulle connessioni inferiori a 300 Mbps.

Esistono inoltre router e firmware che implementano direttamente CAKE, FQ-CoDel o tecniche equivalenti. Non è quindi essenziale che nell’interfaccia compaia la parola “SQM”: conta verificare quale algoritmo usa realmente la funzione QoS.

OpenWrt: configurazione essenziale

Con OpenWrt basta installare luci-app-sqm, aprire Network, SQM QoS, scegliere la WAN e partire con:

1. Queueing Discipline: cake
2. Queue Setup Script: piece_of_cake.qos
3. Download/Upload: circa 85-90% della velocità reale.

Poi si aumenta progressivamente il rate fino a trovare il punto oltre il quale la latenza torna a crescere. OpenWrt raccomanda CAKE come prima scelta e FQ-CoDel quando l’hardware non riesce a sostenere CAKE alla velocità richiesta. Su FTTH da 1 o 2,5 Gbps va infatti considerata anche la CPU: SQM deve elaborare i pacchetti e un router poco potente può diventare esso stesso il limite.

triple-isolate: evitare che un solo dispositivo domini la rete

CAKE non si limita a separare le singole connessioni: la modalità triple-isolate cerca di applicare una condizione di equità anche tra host sorgente e destinazione.

È importante perché applicazioni come BitTorrent o alcuni downloader possono aprire decine di connessioni parallele. Senza host isolation, un dispositivo potrebbe ottenere più banda semplicemente aumentando il numero di flussi.

Hardware Flow Offloading: un dettaglio fondamentale su OpenWrt

Un router moderno può raggiungere velocità elevate grazie all’Hardware Flow Offloading, che permette a parte del traffico di bypassare l’elaborazione normale della CPU.

È ottimo per il throughput, ma può entrare in conflitto con SQM: CAKE deve vedere i pacchetti per poterli accodare e schedulare. Su OpenWrt conviene quindi verificare la specifica impostazione Network, Firewall, Hardware Flow Offloading, disabilitandola quando interferisce con SQM.

Se il traffico bypassa il percorso gestito da CAKE, si può avere una configurazione formalmente corretta che però non controlla davvero tutte le code.

Conclusioni

Il fenomeno del bufferbloat dimostra quanto sia fuorviante valutare una connessione Internet soltanto in termini di Mbps. Una linea da 1 Gbps che aggiunge 200 o 300 ms di latenza appena viene saturata può risultare, nell’uso quotidiano, meno efficace di una connessione più lenta ma capace di mantenere il ping quasi invariato sotto carico.

Gli interventi sul singolo PC possono essere utili per diagnosticare il problema o limitarne temporaneamente gli effetti, ma non sostituiscono una corretta gestione della coda nel router. La soluzione più solida consiste nel fare in modo che il collo di bottiglia cada su un dispositivo che possiamo controllare, eventualmente riducendo di pochi punti percentuali la banda disponibile e affidando poi la gestione dei pacchetti a tecniche come SQM, FQ-CoDel o CAKE.

Non serve necessariamente installare OpenWrt: anche un buon sistema di QoS o traffic shaping integrato nel router può essere sufficiente, se riesce a mantenere bassa la latenza sotto carico. OpenWrt, OPNsense, UniFi e altre soluzioni diventano particolarmente interessanti quando si vuole avere un controllo più preciso su shaping, fairness tra host, overhead della linea e comportamento delle code.

Il criterio finale, quindi, non dovrebbe essere “quanto riesco a spremere dalla mia connessione?”, ma qual è la massima velocità alla quale la connessione resta reattiva anche quando download e upload lavorano al limite.