BBR (Bottleneck Bandwidth and Round-trip propagation time) es un algoritmo de control de congestión TCP desarrollado por Google y publicado en 2016. Al contrario de los algoritmos históricos fundados en la pérdida de paquetes, estima de forma continua el ancho de banda disponible y el RTT mínimo del camino. Entender su funcionamiento permite evaluar lo que su despliegue por un proveedor VPN puede aportar realmente a la velocidad.
Por qué existe el control de congestión
TCP debe regular su velocidad según la capacidad del camino, so pena de saturar los buffers intermedios. Durante tres décadas, los algoritmos dominantes (Reno, luego CUBIC) usaron la pérdida de paquetes como señal: en cada pérdida, se reduce la ventana de congestión. Lógica reactiva con dos defectos documentados: en buffers poco profundos, pérdidas transitorias (sin saturación real) hacen bajar inútilmente la velocidad; en buffers profundos sin gestión activa de cola, CUBIC llena la cola permanentemente sin disparar pérdida —velocidad elevada pero latencia que se dispara (bufferbloat)—. BBR responde a ambos problemas modelando el camino en lugar de reaccionar a la pérdida.
Lo que BBR mide
BBR apunta al punto óptimo de Kleinrock: emitir a la velocidad del cuello de botella, sin cola persistente. Mide de forma continua dos parámetros: BtlBw (ancho de banda en el cuello de botella, según la velocidad de entrega) y RTprop (RTT mínimo observado, o sea la latencia de propagación pura). Deriva de ello el producto ancho de banda-retardo (BDP = ancho de banda × RTT; ej. 1 Gbit/s × 150 ms ≈ 18,75 MB) y mantiene el volumen de datos en tránsito cerca de ese BDP, controlando la emisión por pacing (espaciado de los paquetes) en lugar de una simple ventana. En los caminos con RTT largo, CUBIC puede no alcanzar nunca ese umbral antes de que una pérdida reduzca su ventana; BBR lo sortea pilotando directamente el pacing. Su máquina de estados encadena STARTUP (crecimiento exponencial), DRAIN (vaciado de cola), PROBE_BW (donde pasa lo esencial del tiempo, ciclo de sondeo ±25 %) y PROBE_RTT (medición periódica de un RTprop limpio).
CUBIC vs BBR
CUBIC (especificado en la RFC 9438, algoritmo por defecto en Linux, Windows y Apple) gobierna la ventana mediante una función cúbica, independientemente del RTT. Diferencias clave: señal de congestión reactiva (pérdida) para CUBIC, proactiva (modelo BtlBw+RTprop) para BBR; en buffer profundo, CUBIC mantiene la cola llena (bufferbloat) mientras que BBR contiene mejor la cola vía pacing y control del inflight; regulación por ventana (CUBIC) vs pacing + ventana (BBR). La equidad es buena entre flujos homogéneos de ambos lados, pero BBRv1 tiene problemas documentados de equidad hacia CUBIC.
BBRv1, v2, v3 y QUIC
Según los estudios de APNIC (2019–2020), BBRv1 presenta defectos documentados y cuantificados. Sobre la equidad hacia CUBIC, un estudio presentado en IMC 2019 (Stony Brook University, publicado en el APNIC Blog en enero de 2020) muestra que el resultado depende fuertemente del tamaño del buffer del cuello de botella: con un buffer reducido (10 KB), BBRv1 puede acaparar más del 90 % del ancho de banda total frente a flujos CUBIC concurrentes; con un buffer amplio (10 MB), CUBIC recupera cerca del 80 % de su parte. Sobre las retransmisiones, el mismo estudio mide que BBRv1 puede provocar hasta 100 veces más que CUBIC en equipos con buffers poco profundos (100 KB en su protocolo de prueba) — un goodput elevado, pero al precio de una tasa de pérdida aplicativa potencialmente problemática. Estos desequilibrios, que la literatura de redes llama TCP-friendliness, motivaron la creación del grupo de trabajo IETF CCWG, encargado de estandarizar BBR y corregir sus problemas de coexistencia. BBRv2 integra explícitamente las señales de pérdida y de ECN en el modelo, reduciendo la agresividad hacia CUBIC y la tasa de retransmisiones — pero no está integrado por defecto en los kernels Linux de uso general. BBRv3, presentada por Google en el IETF 117 (julio de 2023) y luego en el IETF 119 (marzo de 2024), documenta una reducción de aproximadamente 12 % en la tasa de retransmisiones y una leve mejora de latencia en rutas de alto BDP — pero persisten degradaciones de equidad con CUBIC en buffers profundos según mediciones publicadas en ACM Computing Surveys (2024/2025). Aún no se ha publicado ningún RFC para BBRv3; su integración al kernel Linux mainline sigue siendo un objetivo anunciado, no un estado logrado. BBR no se limita a TCP: se aplica a todo transporte que disponga de acuses de entrega, con implementaciones para TCP y QUIC. Las pilas QUIC no comparten todas el mismo algoritmo (NewReno, CUBIC, variantes de BBR) —pertinente en contexto VPN, experimentando algunos proveedores (Mullvad por ejemplo) con QUIC como transporte de túnel—.
Cuándo BBR ayuda en contexto VPN
Desplegado del lado del servidor por un operador VPN, BBR puede aportar una ganancia de goodput medible: en RTT largo (> 80–100 ms, donde CUBIC subutiliza los enlaces de alto BDP), en pérdidas aleatorias no ligadas a la congestión (BBR no reduce su velocidad si BtlBw es estable), y en congestión real con buffer profundo (mejor manejo de la cola). A la inversa, en RTT corto (< 20 ms) y enlace no congestionado, el efecto es marginal a nulo (CUBIC alcanza ya los límites físicos). En presencia de numerosos flujos CUBIC concurrentes, la equidad de BBRv1 se degrada.
Lo que el usuario no puede verificar
BBR opera del lado del servidor, en las conexiones TCP salientes del servidor VPN hacia los destinos finales. El usuario no tiene ninguna visibilidad sobre el algoritmo activo en el extremo remoto: el cliente VPN no lo expone, y herramientas como ss -i solo ven la conexión local, no el segmento saliente de un servidor remoto. La verificación confiable es imposible desde el cliente. Cuando Proton indica usar BBR en su documentación sobre su acelerador VPN, eso corresponde al segmento TCP saliente servidor→destino —una mención creíble pero no verificable de forma independiente, cuyo efecto depende del camino real, de la topología de los buffers, de la proporción de flujos CUBIC concurrentes y de la versión desplegada—.
Lo que se puede afirmar sin extrapolar
BBR no es «mejor en todas partes»: sus ventajas son condicionales (RTT elevado, pérdidas aleatorias, topología de los buffers). La mención de BBR por un proveedor es un indicador técnico creíble, no una garantía de resultado: el efecto depende de variables fuera del alcance del usuario final, que tampoco puede verificar qué algoritmo está realmente activo del lado del servidor.
Referencias: Cardwell et al. (2016), «BBR: Congestion-Based Congestion Control» (ACM Queue); RFC 9438 (CUBIC); Internet-Draft IETF CCWG sobre BBR; presentaciones IETF 117/119.