Compararea BBR cu CUBIC pare simplă: schimbi algoritmul de congestion control, rulezi un test de viteză și notezi cine „câștigă”. În practică, un astfel de test poate fi înșelător dacă nu controlezi latența, pierderea de pachete, coada, pacing-ul, versiunea de kernel și încărcarea sistemului. Pentru utilizatorii Linux avansați, diferența dintre un benchmark util și unul decorativ stă în reproductibilitate.
CUBIC este un algoritm TCP congestion control standardizat prin RFC 9438 și este folosit pe scară largă în Linux, Windows și Apple, potrivit documentului IETF. El a fost gândit pentru rețele rapide și pe distanțe mari, unde creșterea liniară de tip Reno poate utiliza slab conexiunile cu produs mare lățime de bandă–întârziere.
BBR, dezvoltat de Google, abordează problema diferit: încearcă să estimeze lățimea de bandă disponibilă și RTT-ul minim, în loc să trateze pierderea de pachete ca semnal principal de congestie. Google notează în documentația BBR că algoritmul a fost introdus în kernelul Linux și că suportul de pacing este important pentru rezultate bune, mai ales pe servere încărcate.
De ce nu ajunge un simplu test de viteză
Un test făcut pe internetul real include prea multe variabile: rutare schimbătoare, trafic concurent, Wi-Fi instabil, servere aglomerate, NAT, bufferbloat sau limitări impuse de furnizor. Dacă azi BBR pare mai rapid decât CUBIC, iar mâine rezultatul se inversează, nu ai aflat neapărat ceva despre algoritmi. Poate ai măsurat doar zgomotul rețelei.
Pentru un benchmark corect, condițiile trebuie controlate. Aici intră tc netem, qdisc-ul Linux pentru emularea rețelei. Pagina de manual tc-netem arată că poate introduce delay, jitter, loss, duplication, reordering și rate limiting. Cu alte cuvinte, poți construi scenarii repetabile: conexiune cu latență stabilă, legătură cu pierderi mici, rețea cu jitter sau limită fixă de bandă.
Rolul pacing-ului
Pacing-ul înseamnă trimiterea pachetelor într-un ritm controlat, nu în rafale bruște. Pentru BBR, acest lucru contează mult, deoarece algoritmul încearcă să mențină fluxul aproape de capacitatea estimată a legăturii fără să umple inutil cozile.
În Linux, qdisc-ul fq este proiectat pentru per-flow pacing. Pagina de manual tc-fq precizează că fq poate respecta cerințele de pacing setate de stiva TCP și că aplicațiile pot folosi SO_MAX_PACING_RATE. Documentația kernelului menționează și parametrii tcp_pacing_ss_ratio și tcp_pacing_ca_ratio, folosiți de stiva TCP pentru rata de pacing în slow start și congestion avoidance.
De aceea, un test BBR versus CUBIC ar trebui să noteze explicit qdisc-ul folosit. Dacă într-un scenariu rulezi BBR cu fq, iar în altul CUBIC cu altă coadă, nu mai compari doar algoritmii TCP.
Cum arată un benchmark reproductibil
O metodă sănătoasă începe cu două mașini Linux sau două namespace-uri/containerizări izolate, o interfață controlată și o versiune de kernel notată. Se fixează algoritmul TCP pentru fiecare rundă, de exemplu bbr sau cubic, apoi se aplică aceeași regulă netem pentru toate testele din scenariu.
Pentru fiecare rundă se notează: versiunea kernelului, algoritmul congestion control, qdisc-ul activ, delay-ul configurat, pierderea de pachete, rata limitată, dimensiunea bufferelor, durata testului și numărul de repetări. Rezultatele relevante nu sunt doar throughput-ul mediu. Merită urmărite și RTT-ul, variația RTT-ului, retransmisiile, stabilitatea debitului și comportamentul când apar pierderi.
Un scenariu util poate testa, separat, o legătură cu latență mică și pierderi zero, una cu latență mare, una cu pierdere mică de pachete și una cu limită strictă de bandă. Important este ca fiecare condiție să fie schimbată pe rând. Dacă modifici simultan delay, loss și rate, devine greu să înțelegi cauza diferenței.
Ce nu trebuie concluzionat prea repede
BBR nu este automat „mai bun” în orice rețea, iar CUBIC nu este „învechit” doar pentru că are alt model. CUBIC are implementări mature și comportament bine cunoscut. BBR poate performa foarte bine în anumite condiții, dar rezultatul depinde de kernel, pacing, qdisc, bufferbloat, competiția cu alte fluxuri și topologia testului.
Un benchmark responsabil nu publică un câștig procentual fără context. Dacă nu ai verificat condițiile de rețea și nu ai repetat testele, rezultatul trebuie tratat ca observație locală, nu ca regulă generală.
Pentru administratori, dezvoltatori și echipe DevOps, valoarea reală a unui astfel de test nu este să declare un campion universal. Valoarea este să afle ce algoritm se potrivește propriului trafic: API-uri cu multe conexiuni scurte, transferuri mari, streaming, replicare între centre de date sau conexiuni cu latență ridicată. Cu tc netem, fq pacing și documentarea atentă a condițiilor, comparația BBR versus CUBIC devine o măsurătoare tehnică, nu o impresie.
