Por que existe controle de congestionamento
TCP precisa ajustar sua velocidade à capacidade do caminho para não saturar os buffers intermediários. Por três décadas, Reno e depois CUBIC usaram a perda de pacotes como sinal: cada perda reduz a janela de congestionamento. Essa lógica reativa tem dois problemas documentados: em buffers pouco profundos, perdas transitórias sem saturação real reduzem a velocidade desnecessariamente; em buffers profundos sem gerenciamento ativo de filas, CUBIC mantém a fila cheia sem provocar perdas: velocidade alta, mas latência que dispara (bufferbloat). BBR responde aos dois problemas modelando o caminho em vez de reagir à perda.
O que BBR mede
BBR busca o ponto ideal de Kleinrock: transmitir na velocidade do gargalo sem fila persistente. Mede continuamente dois parâmetros: BtlBw (largura de banda no gargalo, conforme a taxa de entrega) e RTprop (RTT mínimo observado, isto é, a latência pura de propagação). Disso deriva o produto largura de banda-atraso (BDP = largura de banda × RTT; por exemplo, 1 Gbit/s × 150 ms ≈ 18,75 MB) e mantém o volume em trânsito perto desse BDP, regulando a transmissão por pacing , espaçamento dos pacotes, em vez de uma simples janela. Em caminhos com RTT longo, CUBIC pode não atingir esse limite antes de uma perda reduzir sua janela; BBR contorna isso controlando diretamente o pacing. Seus estados são STARTUP, crescimento exponencial, DRAIN, esvaziamento da fila, PROBE_BW, onde passa a maior parte do tempo com ciclo de sondagem ±25%, e PROBE_RTT, medição periódica de um RTprop sem interferência.
CUBIC vs BBR
CUBIC, definido na RFC 9438 e padrão em Linux, Windows e Apple, regula a janela por uma função cúbica independentemente do RTT. Diferenças principais: sinal de congestionamento reativo (perda) para CUBIC, proativo (modelo BtlBw e RTprop) para BBR. Com buffer profundo, CUBIC mantém a fila cheia, causando bufferbloat; BBR a controla melhor por pacing e controle dos dados em trânsito. CUBIC regula por janela; BBR por pacing e janela. A equidade entre fluxos homogêneos é boa nos dois casos, mas BBRv1 tem problemas documentados de equidade em relação a CUBIC.
BBRv1, v2, v3 e QUIC
Segundo estudos da APNIC de 2019–2020, BBRv1 apresenta problemas documentados e quantificados. Um estudo da Stony Brook University apresentado na IMC 2019 e publicado no APNIC Blog em janeiro de 2020 mostra que a equidade com CUBIC depende muito do buffer do gargalo: com 10 KB, BBRv1 pode concentrar mais de 90% da largura de banda total diante de fluxos CUBIC concorrentes; com 10 MB, CUBIC recupera cerca de 80 % de sua parcela. O mesmo estudo mede que BBRv1 pode provocar até 100 vezes mais retransmissões que CUBIC em equipamentos com buffers pouco profundos, de 100 KB no teste: velocidade útil alta, mas perdas na aplicação potencialmente problemáticas. Esses desequilíbrios, chamados na literatura de redes de TCP-friendliness, motivaram o grupo IETF CCWG, responsável por padronizar BBR e corrigir a coexistência. BBRv2 integra explicitamente perdas e ECN ao modelo, reduzindo a agressividade diante de CUBIC e as retransmissões, mas não está integrado por padrão aos núcleos Linux de uso geral. BBRv3, apresentado pelo Google na IETF 117 em julho de 2023 e na IETF 119 em março de 2024, documenta uma redução de cerca de 12 % nas retransmissões e uma leve melhora de latência em caminhos de alto BDP. Persistem perdas de equidade com CUBIC em buffers profundos segundo ACM Computing Surveys, 2024/2025. Ainda não há RFC publicada para BBRv3; a integração ao núcleo Linux principal continua sendo um objetivo anunciado. BBR não se limita a TCP: aplica-se a transportes com confirmações de entrega, incluindo TCP e QUIC. As pilhas QUIC não usam todas o mesmo algoritmo, como NewReno, CUBIC ou variantes BBR; isso importa para VPNs, pois alguns provedores, incluindo Mullvad, experimentam QUIC para transportar túneis.
Quando BBR ajuda em uma VPN
Implantado no servidor por um operador VPN, BBR pode melhorar a velocidade útil de forma mensurável: em RTT longo (acima de 80–100 ms, quando CUBIC subutiliza conexões de alto BDP), com perdas aleatórias sem congestionamento (BBR não reduz a velocidade se BtlBw permanece estável) e em congestionamento real com buffer profundo, por melhor gerenciamento de filas. Por outro lado, em RTT curto (abaixo de 20 ms) e conexão sem congestionamento, o efeito é marginal ou nulo, pois CUBIC já atinge os limites físicos. Com muitos fluxos CUBIC concorrentes, a equidade de BBRv1 piora.
O que o usuário não pode verificar
BBR opera no lado do servidor, nas conexões TCP de saída para os destinos finais. O usuário não vê o algoritmo ativo na ponta remota: o cliente VPN não o expõe, e ferramentas como ss -i veem apenas a conexão local, não o segmento de saída de um servidor remoto. Uma verificação confiável é impossível pelo cliente. Quando Proton informa que usa BBR na documentação de seu acelerador VPN, isso se refere ao segmento TCP de saída servidor-destino. É uma informação plausível, mas não verificável de forma independente cujo efeito depende do caminho real, dos buffers, dos fluxos CUBIC concorrentes e da versão implantada.
O que se pode afirmar sem extrapolar
BBR não é “melhor em todo lugar”: seus benefícios dependem do RTT, das perdas aleatórias e dos buffers. Sua menção por um provedor é um indicador técnico plausível, não uma garantia de resultado: o efeito depende de variáveis fora do alcance do usuário, que não consegue verificar qual algoritmo está ativo no servidor.
Referências: Cardwell et al. (2016), “BBR: Congestion-Based Congestion Control”, ACM Queue; RFC 9438, CUBIC; Internet-Draft IETF CCWG sobre BBR; apresentações IETF 117/119.